Well, as I tried to say in at least one of the articles and maybe this wasn't clear enough, this is not about me. I am pretty fluent in HTML and CSS, usually, I was the guy who told people what they should do to comply (I have an article on how to write better HTML too, btw). However, I think that it is a classic old reasoning to blame people for not adapting to things that are, in fact, very hard to adapt to. As any designer will tell you, things should adapt to people, not the opposite.
About HTML, this is, rather, pointing to the failure of a conceptual assumption (semantic tags) that most people simply don't get completely right. You see, most people write a section here, an aside there, an article on blog templates, but in the end, they fall back to the ol' div. You can criticise developers for that as much as you want, that's fine for me, I wasn't happy with them for a long time too. But this is human nature after all: we as humans have a limited attention span and limited room for things in our heads. For a Buddhist reference, we always tend to take the path of the least effort and, in this case, this path is the one where HTML means strictly functional tags, div/span and only a couple more. Whether either of us wants it or not, people are too pressed for deadlines and busy with their errands to care about fine-tuning tags when they don't see tangible results from it, ending up prioritising the most important things, which today mean JavaScript in our front-end world.
In fact, even when you get semantic HTML more or less right as I think I often did, it is quite open to interpretation so I wonder whether the tag name was ever a reliable piece of information. Like I said in the article, Google moved on because they want to offer people what matters, which is content. Accessibility tools are also moving on because of the same reason. In the age of AI, we are still trying to make people use manual processes prone to error like dozens of aria-* rules that, for the reasons stated above we should know they will not be used right. This is not leaving accessibility to the corner, this is being realistic and trying to point to feasible solutions, that would work with human developers.
There is another factor that is very important: how many of all developers speak English, and how many among them speak it well enough or without any regional biases to understand those tags exactly as they should be understood by the people who established their standard meaning? It seems too self-centric from the native English speaking world to just assume that the whole planet will tell all these many tags apart and use the right ones. This is about a whole world of developers, literally.
About CSS, more than being an absolutely wrong concept, it is more about being a concept that is wrong for the crowd. Developers wanted variables, functions, reusable structures that seem familiar and, instead, they got the cascading selector-oriented rules that make most of them scratch their heads, again, whether either of us want it or not.
I know that building stuff with CSS natively is possible, I did it myself for almost a decade. Whenever the project was too big, though, I got extra jealous of the stylesheets and kept people away from it like a mother protecting my breed because I know that messing with it was the easiest thing possible. When I moved on from the original CSS concept, using Bootstrap (that I don't like that much) or other tools like CSS-in-JS, I never had this feeling again, it was liberating. At this point, when CSS was not strictly CSS anymore, I finally felt I could trust other people in its maintainance.
See, I kinda agree with you that native HTML and CSS may be simpler to use than the other solutions people are using right now (not only because they are native). I get your point about those tools being complicated, they indeed are. Nevertheless, it is less about being complicated or not and more about how they are more suited to the way programmers minds' usually work and how do we approach working in teams with CSS. Working with JS (or whatever else) together with CSS requires people to switch between two mindsets, the programming mindset and the CSS "custom" one, and a lot of people are just not good at this. Should we expect they were? I don't even know about myself, as now with 42 I just want things to be more efficient and streamlined, and CSS-in-JS got me to a place where I feel comfortable (not perfect, but okay for now), especially in a team, with other human beings. Again, human beings. Most developers I know are very good at focusing, and this is all about focus, about consistency towards a standard mindset.
Regardless, Bootstrap, Tailwind, Styled-components or other similar solutions are just too successful for someone to say that this is just plain laziness. The fact that JS came to be that important was certainly not gratuitous too: if things went this way that was because there was some dissatisfaction with the original Web stack. It is not always painless to work with NPM, package managers, frameworks. All these layerings have to offer something, because otherwise people would certainly not bother (again, they always tend to stick to the path of least effort).
In the end, as much as this conversation is interesting I think the corridors of power are an ocean away and the big browser guys will decide about whether anything should be done. I don't think they will change radically anything though. So a lot of people will keep using tools to bypass HTML and "fix" CSS until WebAssembly (probably) comes with a cleaner solution for this. Maybe this will make everyone happy: most devs will not be obliged to generate HTML and CSS as a bureaucratic requirement and people who may like the current stack can just keep doing things the way they want.
