It depends a lot on the rate of change of the document.

Documents that experience little change don't need classes because their structure is reliable.

Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.

It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.

There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.

My middle ground is semantic classes but also use the element names, as they are already semantic. I use IDs only for JavaScript. No hierarchical class names, no Tailwind, no code compressing, no Uglifiers. My code shall be a pleasure to read and modify.

My proposed viable middle ground approach would be to adopt markdown as an intermediate representation and use some build process to generate the final output. As long as the input is markdown, it doesn't matter if the final output from the build process maintains tight coupling between structure and styling. That said, if the primary benefit of the no-class approach was intended to facilitate development, this method—which introduces an additional build step—would be counterproductive.

The problem is that, in the current state of CSS, it's a two way binding: The styles are dependent on structure to make the look, and the structure is dependent on styles to make the look. Often times you wind up needing to add a wrapper div, either to give a root for selectors or to provide some CSS context like stacking, containers, perspective, etc. And when you add that container class, your classes that are structural often all break in difficult to debug ways.

I used to follow CSS Zen, now I'm more of a "put a class on every element describing its purpose semantically". Then, when I need to change the structure of some component, adding a wrapper, changing an element type a -> button, etc, most of my styles keep working just fine. I'm not a fan of Tailwind, my method is more like BEM or Atomic CSS but with less naming-convention-rigour.

I should mention that most of my work is in building interactive components. You might be able to make the case for structural css for more flow-like content. But even then, when designers start asking for full-bleed elements in flow, you have to start breaking structural semantics and tying the two together.

Because a <ul> can be either a horizontal nav bar or a vertical list. Without differentiating the <ul>, how would you style it?

Another pitfall is SEO: the SEO team might tell us they need a certain element on the page to be an h2, for SEO purposes, but it needs different styling than other h2s on the page.

MUI solves this problem by having different typography sizes defined in the theme, and then you specify variant=“h2” on an arbitrary Typography component and all the styling is consistent.

One more reason I always choose or recommend MUI for all new projects.