Not out of the box, and the things they have to do to make it scale would make most devs cry.
I've seen it up close and personal.
WordPress out of the box is good for a low traffic blog. Even then it's not well designed software.
My team did the migration and build-out of The New Yorker and its relaunch on WordPress. I launched Quartz (qz.com) originally on WordPress (acquired and moved to in-house CMS then at G/O Media), and other media orgs since then.
Sure, not "out of the box" but not the way you mean. There was a design to be put in place, but no more than any other CMS...
If your devs are being made to cry then you are doing it wrong?
That's pretty much what I mean. Most CMS platforms on high traffic sites need caching, but not to the extent WordPress needs to be buffered. I've seen some ugly stuff that was solved very quickly by using a more robust CMS. I suspect you have too.
There are advantages to it for a newsroom but not enough to make me ever consider reaching for it in 2023.
> If your devs are being made to cry then you are doing it wrong?
I disagree with this. If I make people use the wrong tool then I'm doing it wrong.
> Most CMS platforms on high traffic sites need caching, but not to the extent WordPress needs to be buffered
I continue to disagree with you on the WP side. Setting up with a CDN was not difficult. First with Akamai and later moved to Fastly for the ESIs. No more effort required of any other CMS - thats not at WP specific.
In terms of WP specific work that was required, again, not a big effort. Caching was not an issue for us on that side. We made use of Transients API here and there for some larger queries (curated homepage) but no big hurdles.
> If I make people use the wrong tool then I'm doing it wrong
I'll stick with my original meaning. The tool is fine if you know how to use it. I'm able to demonstrate that that WP is fine for several high-traffic sites. Some of which were getting ~30M unique visitors (not pageviews) a month without being on fire.
Its very possible your editorial workflow requirements, or other site needs were very different from ours, and we did not need to contend with those pain points. We were fairly ruthless about what plugins we'd allow and they'd been mostly pre-vetted or semi supported by WP/Automattic.
So was I. But when I realized that commercial and even bespoke CMS' often blew WP out of the water I really changed my tune. And amazingly they ended up being cheaper, more performant and more secure.
Can you make it work? Yes. Should you? Very tough question. I can't see too many cases where I would reach for it.
Generally it's because there are few commercial CMS companies left and media orgs are not software development companies.
So neither solution is ideal and most media companies operate in a 5-10 year loop of dissatisfaction and change.
You can even use WordPress as the backend to a static website (via Jekyll, Hugo, etc) with extremely minimal effort. I did this nearly a decade ago for a webpage with tens of thousands of content pages and a million uniques/day.
I then served it from a trio of $10 AWS boxes serving a very vanilla nginx configuration and a cloud loadbalancer. We didn't even bother paying for a CDN because it was never necessary. WordPress backend was on Pantheon and only accessible by employees via SSO.
The entire migration (from just serving WordPress), redesign, pipelining, setting up Solr for site search, etc was all done by one developer in about 3 months...including training the content writers to use Markdown.
You set up your wordpress with custom post types and I wrote a Jekyll Generator plugin that builds content from a SQL query to WordPress' database. The whole pipeline to build and publish an update to the static site was around 5 minutes...with most of the build-time being eaten up by webpack to do its thing. Probably could have shaved off more time but at that point who cares.
There are also WordPress plugins that can do this now, but understanding how WordPress stores data in its database is dead-simple.
For a static site, a lot of tricks were pulled off to serve dynamic content and the site was still pretty tight and speedy. You can still get reliable Date stamps and CSRF tokens for formfills and stuff like that using nginx SSI.