I'd agree with your assessment. We're testing an SSG with an international website to see what the experience is like. We've traditionally used Drupal, although we use almost zero of the CMS-functionality of Drupal (hence why we were looking at SSGs). We're using Hexo for this deploy. Here's what we've found:
- For complex web pages with a lot of design, we have to put most of the content into .jade files - mainly because of the style of our webpages (long-single-page style with a lot of sections). If we were doing a more traditional page structure, then we could have markdown files. This is "ok" but requires content authors to get into .jade files which can be a little intimating. (if anyone has any thoughts about how to get around this, I'm open to hear them).
- We're storing the files in Github, but have now figured out that if we want a distributed team to work on this, we'll need something like Jenkins to auto-deploy to a staging server on commit. The problem is that the first thing people want to do once they've made an edit check the page to see if it worked. This is trivial in WP or Drupal, but without Jenkins in place, I don't see an obvious way to do it unless we have the content folks run Hexo locally (which I'd like to avoid).
- Huge improvement in the speed of the site vs. the Drupal website. Not shocking given the move to static files, but there is also a reduction in javascript - some of which was coming from Drupal.
- Nice to have all content under source control.
All in all, it's a bit of a mixed bag at the moment - the SSG is supposed to be a simplification of our stack, but now we have to run Jenkins to manage deploy (probably not a bad thing but no one here is an expert in it), and our content people are finding it a bit intimidating.
My worry: we setup all this stuff, and then someone key on the engineering team leaves and we're left with an overly complex stack vs. just going with Wordpress.