I'm so glad I no longer have to wonder what primary means, let alone the other weird names people come up with for classes.
And if you don't want to see the classes, just write it out into a reusable component called PrimaryButton, if that floats your boat.
The point is exactly that you don't need to worry about styling in the HTML. You just structure the HTML. If you want to know what primary means that you open the css file and search .primary and see all the css properties right there. It was never rocket science.
The HTML was designed to be the structure of the site. So you can designate items as buttons, primary buttons, secondary buttons, success buttons, and so on. Then in the Style document (CSS) you would design what you want a button to look like, what a primary button would look like, how a secondary button should look like and so forth. Then together you have a website. If you want to change the primary color of the company from blue to purple than you change it in one place in the CSS and now the website is updated. If you want all the buttons to have a new hover state then you add it in one place in the css and the HTML doesn't need to know or care about it, but it updates everywhere. It was a simple system. Now we are designing inline in HTML.
Yes you could abstract it with frontend javascript components like you suggest. But thats like building a boat to cross a puddle. Not to mention it just brings you back to the original semantic styling context, but using multiple unneccessary layers of abstraction over what could be simple CSS. You suggest using tailwind to put into a react component, just to style a button with a semantic name. When you could use native css to do exactly the same thing with no dependencies or integration workflow required.
For me personally, I've rarely had a design to implement that didn't require a bunch of scaffolding html to conform to the design, css alone was never enough. But that means for all but the most trivial of changes you will need to touch the html and the css.
So the question becomes, is it worth maintaining that separation?
My experience has been that most sites get built, get signed off on, run for some number of years before the site get redesigned and rebuilt, we're rarely making changes to a site that are just simple like the colour of something, all that was decided during development, most of it was signed off on during the design phase even.
So I think that's the angle Tailwind fans take, if the point of separating css from html is to allow for easy changes to the design, but those changes are either never required or can't be achieved via css alone, what's the point? Better to go inline because the development process is quicker and easier.
I don't understand why you think this is like "building a boat to cross a puddle". Folks have struggled with this since the dawn of the web. It's hard.
Most of us aren't crossing puddles, we're trying to cross oceans with gigantic diverse teams.