This only makes sense for a very narrow conception of the range of UI problems. If your UI is just a basic form or trivially reflecting database structure in a CRUD app, then you would have little to no need for React.
If you were to try building e.g. the full Gmail UI and make the attempt with e.g. document.querySelector (or jquery) and again with React you would have a painfully clear understand of the necessity. (And I've selected Gmail here not as an extreme example, but rather as typical of the kind of thing I've seen React getting used to build.)
As far as needing "all this," there seems to be a misconception: React is actually quite compact. If you take into account its entire history (as you might have to if maintaining a legacy codebase), you'd find some inelegant redundancy (mostly just supporting both class and function components)—but if you're just grabbing the latest version and using it for an appropriate problem, I think someone with a sense for good system design would have few complaints.
But that wasn't my argument at all. Gmail isn't even written with React. And if it were it would still be irrelevant: I'm not arguing "writing a program in React means it will be a good and well-designed program"; I'm saying if you write the same complex program twice, once with built-in browser APIs and once with React, you will on average find that the React implementation is far quicker to write, more concise, fewer bugs, and so on.
That's a false dichotomy.
And by all means, if what you're building only requires a very basic UI—absolutely go for it.
My argument is that when you're faced with is an intrinsically difficult UI problem, React (or similar FRP-inspired frameworks which the community has stabilized around) is a huge improvement over the "simpler" past way of doing it. And the only way to really understand that is to try building non-trivial applications with both.
If there is some new system that's a genuine improvement over React and kin I'd love to know about it.
And yes absolutely as I’ve said, if it’s possible to for some domain to have a basic ui do that.
That is a fancy way to say: React gets new devs productive fast, and so it has tons of them available for work, but that comes at the cost of producing more spaghetti that more experienced devs inevitably have to clean up.
This is highly debatable. A lot of conventional and opinionated systems have lots of under-the-hood magic that make it hard to reason about, even for experienced developers.
It seemed to take a lot longer than normal to get comfortable with it as a framework. React still feels like a clever hack sometimes.
That said, I think React is fatally flawed in its necessity to treat state in immutable structures. I wish React could be more like an immediate mode UI library, or a “thin” rendering layer as it was originally advertised. I want to be able to structure and handle my state however I please. I think such a library is bound to come along and topple React.
I'm dealing with thousands of fields with hundreds of different validations (usually min/max values or regular expressions), React is not the only one that can solve this, but at the moment I don't regret my decision. And with hooks and functional components, they're really compact - compared to e.g. Angular, which is more aimed at Java/C# developers I believe in terms of formality and verbosity.
The fatal flaw of React is that there are two states - client and server. Very often two different languages. Two different teams. Long and painful build. And in any case, you cannot trust the client. In 99.99% of the use cases - apart from extreme scale and full page renders - a LiveWiev will be more than enough, at 1/20 of the complexity and development time.
And yes, we use React.