1. It’s assumed that a UI component / microfrontend will be used in many presentations. Consolidating around one framework, especially one that figured out mobile app rendering early on, makes sense.
2. Progressive enhancement is rarely a consideration now. You may or may not agree with that change, but the reality is many large websites simply fail to work if JavaScript does not load. Many of these websites are very popular, and many make lots of money.
3. Desktop UI frameworks became much less popular (especially on Windows). Building a SPA for internal tools, or an Electron app reduced complexity for building those applications and specialized skills.

If you said I had to greenfield a project today, I would say:

• Write the API in whatever (or nothing!)
• Write the UI in JavaScript

What I’ve never said is “do it in React”. But for most of problems I see, React solves it either wonderfully, or fine enough, and it’s rare that

One thing I’ve said and will stand behind forever is that I do not want to compose UIs in the template language that requires me to learn it’s own for loop. The biggest selling point for React for me when it first released was JSX - if I needed to work with data, I could simply write JavaScript. I know people complain about JSX not entirely matching HTML but it’s a small number of properties that don’t overlap.

The other one is that two-way data-binding and using DOM properties to pass data is a terrible design.

The other thing I have said for a slightly less long time is that at some point web components would replace React. What is really needed here is an easy to learn JavaScript framework that does what React Server Side Components will do