I run one of the largest WP installs outside of WP.com, and we've seriously struggled with performance issues. Sounds like a lot of this complaint is a WP design/performance issue. If you're looking to be create a WP serving platform, it will require a huge amount of custom configuration, a huge amount of hardware (even with the best caching), regular DB maintenance and reconfiguration, and core hacks. Automattic redirects the core dev when they need something, generally only enough to add their hooks, then they write a plugin, release it to the community, but always keep it a few versions back (HyperDB support for 3.4 anyone?)<p>The WP core team doesn't write code with performance, scalability, orthogonal design, good standards or any such thing in mind and you regularly hit gotchas. However... if you sign up to be a WP platform, you're kinda asking for it.<p>Obligatory performance tips:
1. Cache the heck out of it. CDN, varnish, optcode (APC), query caching on MySQL.
2. As has been noted, file stat'ing is massive. You have to have an exclusive install as close to each serving node as possible, even with optcode caching.
3. Core hack - Modify admin comment searching. Does 5 column wildcard lookups across the entire table. Not scalable. (<a href="http://core.trac.wordpress.org/ticket/20487" rel="nofollow">http://core.trac.wordpress.org/ticket/20487</a>)
4. Core hack - Remove content reallocation on user delete. With large user tables, you lose the ability to delete users (core fix pending: <a href="http://core.trac.wordpress.org/ticket/19867" rel="nofollow">http://core.trac.wordpress.org/ticket/19867</a>)
5. Clean and optimize your DB regularly - Old post revisions are a huge gain
6. Add indexes intelligently - WP doesn't include all the indexes you need
7. Horizontally scale your DB (whether through MySQL clustering, or HyperDB + DBs with roles)
8. Tune everything. I've found that NGINX/Apache and Percona/MySQL make little difference, but setting the right config for each daemon makes huge difference.