Yes, exactly. This is what I'm actually thinking about.
(I agree that a one-hundred-percent static site is a thought experiment, not a plan; it's not really going to fly in the twenty-first century. I chose the word "dream" in my original post with some care. ;) And "marketing engineering" is a nice concise term to explain why you're going to need dynamic features somewhere on your site, sooner or later, even on something as apparently simple as a personal blog.)
I've seen quite a few websites built on a dynamic CMS with a bunch of optional modules containing tens of thousands of lines of hairy PHP, running on a big pile of heavy-duty high-availability hardware... most of which is apparently there just to be ready to rebuild the Varnish cache as quickly and reliably as possible on the rare occasions when that cache gets cold. (On some sites, the cache never gets cleared except by some unavoidable accident: The performance consequences of trying to rebuild the cold cache under load are too dire to contemplate.) A very high percentage of the actual page loads on such sites are served directly from a Varnish instance, which consumes very few CPU resources and a moderate amount of RAM on a single box.
At some point I began to wonder why we conceptualize such sites as "dynamic sites with a static cache" instead of as "static sites, with a few dynamic elements on some pages, and a perhaps-more-synchronous-than-necessary PHP-based page-generation engine that runs on public-facing servers". There are a bunch of reasons, but I wonder how many of them might ultimately prove to be historical reasons.
There is a very compelling reason to run a dynamic site: for most software businesses, that site is the primary venue for all your "marketing engineering", including SEO, A/B testing, interactivity, &c.
The companies that have this dilemma generally have already excepted the architecture of "public site that is separate from their actual application site", which is a step in the direction of mitigating the impact of the security risk.
Those companies would mitigate the impact even further by hosting the public site in a different data center from their application.
Generally speaking, between "adequately secure CMS site" and "adequately engineered marketing processes", and speaking as a security person with a vested interest in selling everyone on buttoning down security everywhere as much as possible: most startups are doing more damage to themselves by not maximizing marketing engineering than they are by exposing themselves to attack.
I'd suggest a middle ground: designate some large, important swath of your public site as sacred and make it static. Host it with stripped down vanilla Apache or Nginx. Then, where you benefit from dynamicism, expose another resource (like a small EC2 server) in your URL space to implement it. This sounds complicated but is really very easy and gives you some of the benefit of a static site (attacks won't tear down your front page) and all the benefits of a dynamic site.
A rule of thumb, by the way: if you sell a web app on the public Internet, and you haven't done something to have that web app formally assessed for security flaws, running a static brochure site for its security benefits is a premature optimization.