I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow.
The browser already has a UI and DOM framework. Use it. (Yes, I know it's ugly. Such is life.)
SPA frameworks don't re-implement the DOM, they provide an interface to the DOM that is more usable. That may or may not have significant overhead, but it's not a given.
You have these benchmarks to show that "vanilla JS" is faster, but that's not real-world application code. Because of the usability issues, application authors are way more likely to not write optimal vanilla code. In particular, any DOM modification is extremely slow, so redundant modifications are very wasteful. Avoiding those is something that a framework/virtual-dom can do for you, to let you write simpler code.
Furthermore, anybody who writes a real application ends up abstracting the DOM interface, so they're already halfway at an ad-hoc framework. Not abstracting the DOM would result in an insane amount of boilerplate code, which would hamper developer productivity, which would result in even less time spent considering performance.
Disclaimer: All of this is true for applications, not for simple websites with minimal dynamic interaction. You're likely better off rendering those server-side and then attaching a couple of event handlers on page load.
Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.
Few developers complained about JavaScript until Back-end developers became 'Fullstack' and had to start working with it and tried to apply the same mental model they had used with Java or Python etc.
CSS was always something you had to dedicate time to, to master and learn the quirks of the current and past browsers, until Back-end developers decided it was 'terrible' and a race to the bottom of CSS frameworks was created and nobody remembered proper selection or specicifity as BEM was adopted.
HTML was a tool for layout which developers made good choices for thoughtful semantic code, so that it was easily readable, for both man and machine, yet it was a manual process. Then Back-end developers didn't have the time to learn something new and everything is a div and if you're lucky it will have a role.
This is the "if all you have is a hammer, everything looks like a nail" kind of view.
What i believe is, the complexity of developing software has been increasing and we have a lot of pressure specially due to time constraints that we are always reinventing the wheel in order to meet deadlines and try to make things easier.
And the result is always the same: bloat.
I agree that pressure is high and time constraints are tight and this forces people to look for an answer outside of themselves.
The complains about CSS being something that is hard to learn and remember and about its shortcomings and hard maintenance have been here also for years. The thing people acknowledged was that it was improvement over writing it all into html.
Original HTML contained everything that CSS contains now - unseparated. And for that matter, everything is DIV because CSS people and designers like it so. It has nothing to do with backend people who would happily use table everywhere if only they were allowed to. Then again, css people and designers did not pushed for divs out of whim - they want it that way because it is practical for them.
CSS has always been relatively simple, the complexity came about by having to juggle workarounds and hacks to support all the different browsers.
I completeley disagree with your last statement, divs had been around for a long time before they became a one-hit wonder for all elements, nobody needed or wanted them.
Once CSS 2.1 was adopted and table layout was no longer required semantic html ruled.
Divs have only become ubiquitous since CSS and front-end frameworks have become so popular
Also, even things like making stuff same height were absurdly difficult with css even absent browser differences. It is oddly inconsistent language with hard to remember rules.
And it often ends with house of card constructions that break the moment anything changes.
I've read some developers limit their CSS file(s) to 50 lines (max.) while other developers build their CSS on a page-by-page basis dependent on a primary global style sheet (ex: content-sidebar.css is loaded on every static page and post while content-page.css is only loaded on static pages).
Where I currently work at, every static page gets its own CSS if it meets the following two parameters: (1) accessible from the root and (2) not part of a larger (or "nested") set of pages--two rules becomes necessary when you have a team who hates nested pages and prefers an internal taxonomy system. The styles are encapsulated by adding an additional HTML class (usually a sanitized version of the page title and its ID) to the body tag.
For pure CSS websites, OOCSS will be your best friend as it forces serious thought into how you define your style rules. Additional rules also include limiting the use of CSS vars only to elements that have an ID attribute (which is also limited as well).
You can use intercooler.js to wire in very usable modern UX with very little overhead, relying on the native, screaming fast DOM implementation.
Buggy and inefficient stuff sometimes makes sense to a business, this is true.
They also solve problems like state synchronization and mutations that the browser has zero facilities for. As mentioned in another comment above, in any medium sized project you’ll have implemented more than half a framework abstracting the DOM already.