Although I take your point that people do a lot of needless computation these days, I don't quite understand the dig at caching. Isn't adding an HTML file to your server just manual caching?
The way I do this for the CMS/Blog stuff on my products is to set up a 404 handler that looks for urls that seem like they should be blog entries. So if it sees a request for the non-existant http://mysite.com/blog/caching_is_awesome.html, it'll do a quick check for that article in the database, and if necessary create the static .html file before redirecting to it.
It's a little nicer than caching because you only need ever lookup/create the thing once each time it changes. From there, it's just the webserver being a webserver. No need to involve any application layer at all.
That has the added benefit that you can use version control on it.
You have done the webserver equivalent of method_missing trickery in Ruby.
Don't do at run-time what can be done at compile-time.
This doesn't need to be any more manual that the labor involved in uploading content into a CMS or data store by another name (e.g., blog engine). It's more of a substitution of one task for another.
I prefer to think of the static HTML approach as the difference between using Makefiles versus a shell script for compiling code. Once you understand that the shell script will duplicate nuances that 'make' offers, use of Makefiles for compiling code usually gets viewed as the better approach. (There are always edge-cases, of course.)
If a consistent stack is more important, caching may be the best option. If fewer layers of complexity at run-time is more important, out-of-band/pre-processing may be the best option.