Perhaps there are good reasons why this hasn't happened yet, but I'm surprised that the bulk of Wordpress-based websites don't split the editing of content from the display of content.
What do I mean by this? Imagine you have two servers. Server 1 has WordPress installed, and is where you manage your website content. Server 2 does not have WordPress installed, but instead displays a static copy of the WordPress content, which is updated by a script on Server 1 whenever new content is published.
What are the advantages? First of all, Server 1 can be very heavily locked down. You can keep it accessible only over a VPN or ssh tunnel, you can keep it unlisted off search engines, you don't even need to register a domain name for it. Secondly, due to the static nature of the content served on Server 2, site performance and scalability is going to be excellent, and it'd be easy to manage a cluster of "Server 2's" if a single server isn't fast enough.
What are the disadvantages? You have to rely on a third party solution like Disqus if you want to have comments on the content you create. Same for shopping cart functionality. Also, you may not be able to have a Wiki. I can't think of any other disadvantages.
I've done that and it works well, with the limitations you noted - it is static, so there can be no dynamic content (e.g. no comments - a Good Thing^TM - random user's comments are nothing but trouble). Blogs are not a problem, but you have to (manually) refresh the static site after each blog entry. For a business site (what I set up) with essentially static content, that is fine.
I no longer have access to the site, so I'm writing this from memory... I used a standard plugin that generated a static site out of the dynamic content. The plugin was for supporting static site serving on the local server, not a separate server. Being the more paranoid type, I used a Wordpress "authoring" server that was not publically accessible and a separate publically accessible "static" site server. I either had the plugin suboptimally/mis-configured or it had limitations, so I had to run a sed script on the output to change the web server host name from the internal authoring host to the static publically accessible host name (the link paths were fixed up properly). I then rsync'ed the result to the public host (with --delete to clean up obsolete files) using ssh keys for authentication, not passwords. I put this in a shell script, which made it simple and convenient for a sysadmin (me) to use but it was not user friendly for the Wordpress (not really computer literate) users. Not a problem, perhaps even a Good Thing^TM.
That's the idea behind Buster for the Ghost blog framework (run Ghost locally or on a highly restricted web server then generate a static site from it you upload somewhere else) but it doesn't look maintained unfortunately:
https://github.com/axitkhurana/buster
I'd be very interested to know about more solutions like the above as it doesn't seem well explored.
I've had some success running WordPress on Heroku (uploads go to AWS S3 and the database is hosted on AWS RDS) which I much prefer to the way typical VPSs are administrated. The Heroku filesystem doesn't allow the WordPress PHP files to be altered, you can't SSH in to the live server and you can recreate and rollback the whole server state in seconds if there are any problems.
Either way, the more static the better in terms of minimising the attack surface and admin time in my opinion.
You can get the performance benefits with cache servers, and such a workflow isn't really integrated into Wordpress (e.g. can you easily generate a list of all pages affected by a change? Or do you want to crawl the entire site for each update?). Projects that are build with this in mind are probably a better choice.
Yes, you can get the performance benefits with caching solutions like Varnish, but what about the security benefits I outlined above, how do you get those?
You don't. Still, I'm not aware of any tooling around WordPress that makes this a viable strategy for the average WordPress customer, which I guess is the answer why nobody does it.
There is tooling: take a look at roots.cx It has a workflow for using WordPress as a backend to manage a static site (generated by roots): https://github.com/carrot/roots-wordpress
In addition, it's not that hard to come up with a home-grown workflow using WordPress's REST API (now a plugin but soon to become part of the core application). Middleman has native support for generated static pages from a JSON API (dynamic "proxy pages") and it's not hard to make a Jekyll plugin to do the same.
Server 1 is based on the the free tier on OpenShift.
Server 2 is based on the free tier on Google App Engine (or Amazon EC2).
On server 1 you install Apache, WordPress, Varnish and a file sync solution like syncthing.
On server 2 you setup the DNS settings for your site plus the sync client.
On server 1, you have WordPress use the Varnish plugin to automatically populate the Varnish cache with all pages on your site. Syncthing (or something similar, if syncthing doesn't work with GAE or EC2) looks at the Varnish cache folders and pushes all changes to Server 2.
That's about all you need to do. It basically gives you a fast and hack-resistant WordPress website, and you only pay for the site domain name.
What do I mean by this? Imagine you have two servers. Server 1 has WordPress installed, and is where you manage your website content. Server 2 does not have WordPress installed, but instead displays a static copy of the WordPress content, which is updated by a script on Server 1 whenever new content is published.
What are the advantages? First of all, Server 1 can be very heavily locked down. You can keep it accessible only over a VPN or ssh tunnel, you can keep it unlisted off search engines, you don't even need to register a domain name for it. Secondly, due to the static nature of the content served on Server 2, site performance and scalability is going to be excellent, and it'd be easy to manage a cluster of "Server 2's" if a single server isn't fast enough.
What are the disadvantages? You have to rely on a third party solution like Disqus if you want to have comments on the content you create. Same for shopping cart functionality. Also, you may not be able to have a Wiki. I can't think of any other disadvantages.