yes and no.

I spent 4 years at a large financial news company, where we benefited from many ex graunaids who decided to migrate over the river.

They helped us create the new front end to the website, to much acclaim. However, it was hard for a number of reasons(this is from the financial news company, not the gruan.):

1) The journalists hated change, especially as they couldn't see any benefit. They just want to keep their same interface exactly as it is, bugs and all. They also had an active union.

2) There is 20 years of "micro services" moving data from the CMS, through various things to allow stuff like translations, syndications (very important source of money) data extraction, meta data processing, physical page layout, and many many more. Most of which is done by a legacy ETL framework pushing to and from a solaris FTP server that is old enough to join the army.

3) there is more than one way to enter data into the CMS.

4) The type of article, and the data in said article changed depending on where it came from, and what services nobbled it.

5) looking after the journalist's interface, curating the data, sorting the articles and adding meta data, looking after paying subscribers, and finally the front end, were all different departments that refused to talk to each other.

This meant that unlike a rational place, there was no source of truth for the CMS. It wasn't like you could call up article 342923 and display it. There was no guarantee that it would have all of the metadata (like were we allows to publish it) required. Add to that the inter department rivalry, which meant that for some reason the membership department were allowed to spend 4 years re-writing the same bit of functionality over and over again. (user management and payment gateways is a solved issue, but alas it took the best part of 25 million quid to find that out.)

To answer your questions:

1) because it scales maaaaan, looks good on my CV, I don't want to spend time doing boring work, I want to learn a new tool

2) see 1

3) see 1

4) Because I suspect that they've never seen a working ETL system

To answer your bonus questions:

1) Journalists have unions, changing the editor requires a _boat_ load of training, and is almost never worth it. Buy over build every time. But yes, its just text. However its the metadata that makes it. Whos in the article, whats the subject. Is it a lifestyle piece, does it have photos, who owns the copyright for the photos, is the article syndicatable, can we syndicate this article, who edited it. Etc, etc, etc. The text entry is the easy bit, its the parts that make it a real news paper that are hard.

2) Nope, almost certainly never done like that. The article will be given a UUID, and dumped into the CMS DB. The front page generator system will then dynamically pull out the articles based on parameters given first by the editors, (front page image, leading headline etc) then the related articles might be curated by hand, or by keyword/metadata or user's preference.

Then the advertising and tracking bits have to be injected, which account for 50-70% of the effort.

CDNs now allow a lot of logic to be pushed to the edge. (see https://labs.ft.com/2014/10/caching-user-agent-specific-resp...) which means that its not overly taxing to host a very large website.