I think that the issue at play here is basically the same than the debate about FP vs OOP for systems architecture. One tries to encapsulate information, by dis

I think that the issue at play here is basically the same than the debate about FP vs OOP for systems architecture. One tries to encapsulate information, by distributing it, while the other tries to completely separate both. These are differennt strategies leading to different paradigms. Looking at one from the point of view of the other will make you think they are using obvious anti-patterns and just getting it comoletely wrong. But this is somewhat an illusion, because they are in fact trying to achieve different things (or the same things with different strategies). Classical CSS is like FP. It insists in completely separating information (HTML) and operations (CSS). This works well when you have a priory knowledge about the totality of your HTML and its internal structure. Therefore, it works well in small/simple systems or systems with a simple structure (blogs, ...). This model is favoured by designers and developers of "simple" systems (the ones with an a priori known structure). Tailwind and similar frameworks focus in encapsulation and composability. As OOP, they make it easier to compose modules developed by different teams with little coordination between them without risking too many conflicts. They are designed for modularity and scalability. Therefore, this model is favoured by developers using component based JS frameworks like React and targetting very big systems (like FB, Amazon or any similar complex systems). I think that, depending on the context, one paradigm can be more appropriate than the other, but it makes little sense to say that one is right and the other one is wrong as a general statement.