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.
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).