These all turned out to be lousy approaches when it came to UGC, personalisation, migration and URL paths, authenticated content, non-technical business users, team authoring and non-trivial workflows (e.g. picture desks), content reuse and contextualisation, evolving functionality (a split front and back system can require 2 dev streams kept in sync like trying to ride 2 horses).
Integrated back and front end systems was the start of solving these issues and has evolved to SaaS for non-complex use cases. If you look at Wordpress and Drupal, they have been adapting over many years answering these kind of questions and you'll see that they are now starting to address multiple front end channels, PWA and so on.
Old versions of Drupal for example used to allow pages to be rendered to file for faster delivery. However, it turned out that the number of pages grew towards infinity due to dynamic variants of pages (making server and file system into the bottleneck), and that CDN's just became a much better way to do this. Likewise, work was started on a materialised views layer to optimise DB calls until it was discovered that PHP object caching had become very effective and made this redundant.
A static generator could be a good app for a developer to blog but this is niche and it is about the worst choice possible for almost all organisation-based CMS users.
For example, I consulted to a large national broadcaster about 6 or 7 years ago who had created a legacy CMS which rendered XML/XSLT to reduce bandwidth, and the user's browser compiled to HTML in much the same way you describe. It would have been interesting as a tech demo when it was first created about 10 years ago and would have made a good HN blog post. But as a production CMS it was completely unmanageable, prevented them doing the things they wanted to do at a business level, and grew into a tentacled legacy blob which was extremely expensive to migrate off. It was an embarrassment to the tech management and they were open to switching tech even if that meant recycling their large in-house dev team. In the end the cost of their tech experiment which had gone out of control ended up in many millions.
Developers building CMS's is an established anti-pattern with a problem space that is quite hard to understand unless you have been working with users at large orgs for a while. Go and look at how many modules are on WP or Drupal - 10's of thousands, each one which will have had months to years of dev time. Each one represents real use cases that organisations had which was not solved by what developers imagined managing and publishing content to entail.
