Not using a database makes it really simple to install or migrate servers (just copy the directory).
On the other hand, being a dynamic PHP app means there is no explicit build step needed, and you can build any kind of plugin that you need.
I've been running an invite only private beta for a few months now, and most of our early adopters were tech-savvy people who were asked by their friends/family to build a site. They love it because it's less setup and maintenance burden for them. I also plan to open source the project in the coming weeks, so you'd have greater flexibility of hosting it anywhere.
If you like to give a try, request an invite on site (pragma.build) or send a DM (@PragmaApp) on Twitter.
And with a host like Surge or Netlify you can run an entire site for just the cost of a domain name.
The closest I've seen is using Sandstorm with their static Wordpress site publishing but it's still nowhere near as smooth as plain Wordpress.
(Edit: let's add some qualification because downvoting)
When I first started using static sites I would have agreed with you: there's no way I'd hand a normal user a markdown editor and a git repo and expect them to get on with it. But these new services do, in my opinion, solve the experience problem.
However Wordpress is really good if you want to leverage the module ecosystem and do more complex stuff further down the line.
Having used Wordpress for years I get excited about static sites' speed, simplicity and lack of constant security updates but it's not a one size fits all situation.
Forestry.io is a Git-based CMS that commits content changes to your repo (and optionally builds/deploys your site). Contentful is an API-based CMS, that stores your content and requires you to query their API during/after build time.
So you would use Forestry if you're hosting static HTML from CMS, and Contentful for when you need an API for the CMS.
(disclamer: I've never used CMS before so I don't really know how it works)
Edit: Downside(s) would include that $webmaster has to figure out whether to render content at browser or though "ssr".
But having said that, the ecosystem of WordPress is really hard to beat. The original linked post complains that WordPress won't do Markdown without a plugin, but y'know, so what? Jetpack gives me Markdown and great site statistics without Google Analytics. Out of the box, I get a reasonably solid taxonomy system with per-category RSS feeds, threaded comments with Gravatar support, and an API that lets me publish drafts directly from offline clients (including Ulysses, the writing app I was already using). More plugins give me Akismet anti-spam, microformats, webmentions, and per-post crossposting to Tumblr and Dreamwidth. (And Facebook, Medium, and a dozen other systems, if I chose to use them.) There are a lot of things I don't love about WordPress, but the reality is that it's damn hard to beat its user experience.
I'd love it if something else stepped up to be a modern WordPress, but Jekyll, Hugo, et. al. just aren't it. (They're terrific at some things--I maintain a different site with Lektor, using it for things that WordPress wouldn't actually be very good at--but it's not a blog.) Ghost is the closest attempt I'm aware of, but between their launch and their recent 1.0 release, they refocused on being a platform for "building and running a modern online publication. I can't help but feel there's still a real opportunity out there for "modern WordPress competitor," although I don't know if it's a market opportunity--which is, one suspects, why it remains unfilled.
Code quality matters indirectly here. Wordpress is known for it's massive number of security flaws. If you don't watch for new versions and update regularly ( and who has time for that ? ) consider yourself hacked
1. generate your files
2. copy these files to your host
Put these in a script, and your workflow becomes: update your content, then run your script.
Hugo doesn't address that problem at all, nor do Jekyll, which I currently use, and the other similar tools I've looked at.
However, the missing step there (of rendering the static site and publishing it) seems well suited to being done "in the cloud" then on the client device where the posting/editing/typo.
If you have a machine or VM on the Internet to use, this is not difficult to set up for yourself (any computer-proficient user with a little time can do it).
But doing that is also nowhere near as trivial as WordPress makes it (any person at all can do it).
Not Wordpress wysiwyg but still pretty nice.