Well, Facebook was the example provided, and I was just saying that there's a lot of nuance to what (at first) might just look like a static list of posts but really isn't.
I don't think it's a matter of React or not, but how much clientside interactivity & loading you want. If you want more than trivial interactivity -- immediately or in the future -- then a framework makes it a lot easier. Even something like jQuery existed because the DOM was so hard to work with, and thankfully ECMAScript has absorbed some of jQuery's features. React and node are doing something similar, forcing the standardization of ES6 Modules and Web Components, for example. They come up with ideas, implement them, see them adopted, and THEN the standards bodies absorb them.
Nothing stops you from using vanilla JS across your whole project if you want to; many devs just consider it an unnecessary pain that prioritizes purity of ideology over real-world concerns. I disagree that there aren't many moving parts in a typical web UI. Everything today from basic ecommerce to dashboards to maps to search to comments use clientside JS to enhance interactivity and AJAX loading. If you're building something simpler, there's probably no reason to code your own site anymore vs using Wordpress/Shopify/Bootstrap/whatever.
For the more complex cases that full-time devs actually get paid to build, using a framework and dealing with its performance/bundle size considerations is usually easier than using vanilla JS and dealing with its shortcomings, or you end up having to invent a lightweight framework yourself.
That's especially true when you have (or want) a team larger than one person. With a conventions-based framework, any new dev can be pretty quickly onboarded by observing your usage of common patterns in that framework. See a "useState" and "useContext" and they know its intent immediately. If you roll your own system in vanilla JS, without any standard patterns or naming conventions or directory hierarchies, even the most trivial change requires teaching or a deep investigation -- especially once you get into sharing state across more than one component/page.
I mean, this isn't even a hypothetical... the web evolved from basic DHTML-era JS to jQuery to Angular to React and its peers because more and more people saw a need for these frameworks. Nobody forced it on the web community, we just saw how they helped solve problems we had. Many jobs had me rewriting old PHP + JS apps into modern frameworks because, well, it just works better and is easier to maintain afterward.
Facebook itself is an example of that progression. If you remember Facebook when it first launched, it was pretty limited and much slower (in terms of interactivity). (It was also a lot cleaner and not so ad-ridden and toxic, sadly). I think they invented React out of real needs, not "how do we add more overkill to our app".
Sorry... I guess that's just a longwinded way of saying I disagree that there aren't moving parts in a typical web UI anymore, at least in the space of full-time jobs. Small local businesses and whatever, well, they can just use any of the DIY frameworks (Wix, SquareSpace, Square, etc.). But for those of us actually building SaaS or similar products, vanilla just doesn't cut it. Really the only time I can see vanilla JS paying off is simple one-off blogs or lone marketing pages, etc. And most paying dev jobs aren't doing such simple things anymore...
From my experience as a developer, they rewrite frontends in React because it's cool or because their boss said them to do so. Nobody asks if React is really needed in this project and what would be the best solution.
For example, my bank now has an online banking written in React. It's more buggy than the previous version (e.g., the back button does not work; the payment UI is quite chaotic), but they can boast that they use a modern technology. I doubt that a single page application provides any benefit for this task. Their competitor still uses HTML forms and they work perfectly.
This also reminds me of VB6 era. Back then, many programs were distributed with the runtime and/or an installer that was larger than the actual executable. The history repeats now with the bloated web frameworks.
For the last few projects I worked on, we first built super basic prototypes in different frameworks (React, Next, Vue, Svelte, Drupal, Wordpress, jQuery, Symfony, Angular back in the day, etc.) before choosing one to settle on, trying to balance concerns like DX, hireability, UX, hosting & infra costs, whatever.
If I were instead just forced to use a certain framework without doing due diligence, I'd be pretty annoyed too.
Undoubtedly there are people chasing the "new fancy", but also, by now React is considered pretty old and mature and (probably) kinda lame to anyone really wanting the newest edgy framework.
To your point, though, the SPA routing system (and how it interacts with browser history and URLs) is a pain indeed. React Router, in particular, handles it pretty terribly, IMO (it's much better in a system like Next).
This is still besides the point entirely. Somebody looking to learn web programming is not going to start running a bank.
html is on the representation layer, not a programming language. Modern web apps go much deeper and are using js as as a programming language for web programming that can go much deeper. As an extreme example, Quake Live implements an entire transfer protocol over TCP/IP. In the standard OSI model, there are a few layers between this and that. But there is a reason that purely representative documents still prefer PDF.
