I work for 10up, an agency with some big name clients and one of the biggest contributors to WordPress core. Our team loves WordPress, and it continues to be at the center of almost everything we build.
When you work with WordPress, you need to accept it for what it is. It's a CMS that needs to run on a variety of hosting platforms, from a highly scalable, redundant, distributed platform like WordPress VIP down to a $5/month shared host. It needs to support sites built by well-trained engineers who scrutinize every line of code they write for performance & security issues, and it needs to let an amateur bash together some plugins & a free theme to put their business online. Any system that needs to work in such a wide variety of circumstances is going to have compromises.
We rarely use off-the-shelf themes or plugins, and when we do we subject them to an intensive audit. We start with the WordPress Coding Standards for PHP Code Sniffer and move on to a manual review of the code. We only use something if it meets our standards. If it doesn't, we reach out to the original author to see if they'll merge our changes in so everyone can take advantage of our improvements. If not, we'll fork the code so our clients can feel comfortable with the code behind their site.
Our custom code is expected to follow our Engineering Best Practices, which we enforce through code reviews.
WordPress itself has a concept of an Object Cache, where it will store query results so it's not hitting the database constantly. And plugins & themes can take advantage of this feature as well. We prefer memcached for our Object Cache backend. We also tend to use Batcache, a lightweight full-page cache which uses memcached for storage. Of course, it's really best if page requests can skip PHP entirely, so we often add Varnish or Nginx micro-caching to the mix.
WordPress's native search is built to work with a stock MySQL install, so it doesn't get too fancy. So, we've built ElasticPress which connects WordPress to an ElasticSearch no-SQL database and uses it pretty much anywhere WP_Query is invoked. This gives us a highly-performant query engine and the ability to do things like geolocation search results, weighted relevancy, and Unicode normalization for words with accents.
PHP 7's runtime engine gives WordPress a huge performance boost, and there's very few reasons to be running 5.x anymore.
We use tools like New Relic to see exactly how our code performs at scale and tweak things that need it. We've also built our own tools to give New Relic insight into WordPress internals.
And it's not necessarily a performance improvement per se, but building React front-ends that access WordPress through its REST API lets us improve the perceived performance. It also lets us turn our front-end engineers loose building fun, modern web experiences. We're proud of the React-based site we built for WAMU public radio. I remember when having a persistent music/radio player on a site meant using an iframe! It wasn't that long ago!
On the subject of front-end development, we've open sourced a WordPress Component Library enabling rapid development of performant, accessible front-end code on WordPress.
Clients love the WordPress admin experience, and we've built a lot of custom editing experiences that make it easy, maybe even fun, to publish content on the web. Often, these customizations involve React or rely heavily on custom JavaScript for the kind of modern experience people expect. But at the heart of the experience is the same CMS they use to publish pictures of their dogs. So it's familiar and approachable.
I'm the first to admit WordPress has its flaws. But we've used it to build some pretty exciting online publishing platforms over the years and will continue to use it as long as it delivers value to our clients.