Wouldn't caching do a similar thing? I guess you'd have the complexity of removing it from the devserver (so you don't have to wait for the cache to invalidate to see changes), and cache invalidation is always ugly.
Wait, I didn't read the bit about JS and CSS aggregation. OK ... but surely there's other ways.
I think this is "caching", with extremely high latency. And, truthfully for most marketing materials the latency isn't an issue, since approval time are probably much higher.
Really to only reason you'd choose a dynamic language for marketing materials is to ensure link and image relational integrity. (people are bad at this, computers are good)
On the last big site I worked on, we used nginx as a reverse proxy to Apache. That way, nginx respects the cache headers you send out and so nearly every request is served straight from its cache pretty much instantly, and you can have a highly dynamic page without having to worry excessively about performance as long as the response time if you do happen to hit an invalidated cache isn't unreasonable. Seems like a good approach to me if the site requires a dynamic back-end and also requires very high performance, as long as there's nothing on the page which needs to be personalised on the server side (i.e. can't be personalised via AJAX).
Not read the article so not sure if this has anything to do with their reasons for using plain HTML (which, of course, has its place!)
Wait, I didn't read the bit about JS and CSS aggregation. OK ... but surely there's other ways.