I'd recommend not being so quick to dismiss the author. Your suggested alternative is actually way more complex. The approach described sets up a static site generator that allows for deployment to a static asset webhost (like S3/CloudFront). What this means are that there is no server to administrate or manage. Aside from the cost and performance advantages, this drastically simplifies the operational overhead. There's nothing to patch, no networking to configure, nothing. Just upload and be done. Moreover, there's no database at all either. No need to manage database credentials, no need to pay the costs to keep a database running, no need to patch a database server, etc...

This is the total opposite of overengineering. The stack the author is running is way simpler than one where you have to spin up a webserver, database, caching solution, etc...

Having a database for a personal blog seems like overkill.

Not if your "database" is something like SQLite. That is preferable to most alternatives, if you actually want to manipulate data.

If the blog is not much more than a .PLAN file, sure is overkill. But having access to a DB and programming language opens up a few possibilities – and cleaner code compared to hacking some bash scripts doing text manipulation magic.

Now, starting with a database from day zero? I'd say it is a case of YAGNI. Don't add stuff you don't need now. If you need it in the future, then add it. But don't go paying for a hosted DB if a SQLite would suffice.

Oh, and even then, a database would be more useful for the site generation step. Having a DB being called for every page rendered is a recipe for going down with HN traffic (or Slashdot in the older days).

It allows you to do fun things like save comments, post polls, create news items to load on certain days.

Being able to save anything and retrieve can be useful.