Sure, static export plug-ins do exist in plenty, but I don't think that core functionality like this should be implemented as a plug-in.
First, if it isn't enabled by default, most people won't bother to enable it. Second, who knows how long and how well the plug-in will be maintained? Third, if static export is an architectural afterthought, it will probably break unusual features and workflows.
> a) it can lead to considerable complexity as an update to an atom of content may need to propagate to many parts of a site
We shouldn't let perfect be the enemy of good. Even if some blog article from months ago won't get the updated shiny new sidebar, what's the matter? The New York Times still have content from the web stone age on their server [1] - it doesn't use the latest template, but isn't it more important that this content is still available? It probably wouldn't be had they used a dynamic CMS back in 2001.
> b) the whole web is moving towards contextual dynamic delivery.
I'm not talking about amazon.com. They can probably afford proper maintenance of their fully dynamic site.
[1] http://www.nytimes.com/learning/general/onthisday/big/1014.h...
But not using server side dynamism like Drupal provides. It is moving towards sites serving up static files consisting mostly of Javascript that then call data services, so called single page sites.
SQL injection attacks are just as possible against those kinds of apps, although slightly tougher to configure because you need to read client-side JS to find the service URLs, tokens, etc.
Drupal is used to power client-side JS-based sites. The current Tonight Show website is a recent example.