Zack Tollman’s well-researched post on partial page caching in WordPress is the 2nd or 3rd time I’ve heard him mention ESI as a good model for WordPress caching. I’m in full support of that architecture and the ESI format in particular. Some quick thoughts about why:
Requiring an external ESI server isn’t a big leap for complex WordPress sites. Every major advanced-cache solution for WP already requires an external daemon. It’s not even uncommon for PHP — Symfony and Drupal have added ESI support: http://drupal.org/project/esi.
What Jaquith and Ruter are doing should give almost the same performance benefits (admittedly more of WP is loaded), but it falls short from being a shared standard. For example: adding a 3rd-party plugin to a site with that style of on/off caching would require manual modifications in the theme before the 3rd-party plugin data was cached correctly.
That’s where ESI really shines. If the WordPress community standardizes on ESI, then 3rd-party plugins could tag their HTML output in the plugin. A 3rd-party plugin built that way would have drop-in caching support if you were running an ESI server. And, if you weren’t running ESI there would be no negative effects on your site (except a few extra bytes of an ignored tag).
Regarding ESI being proprietary: Even though Akami authored ESI, the standard is well-supported on open source platforms. Even the near-standard nginx platform has an ESI module, https://github.com/taf2/nginx-esi (although it’s possibly a bit stale now).
(edited, corrected tense in 1st sentence)