This [1] is one of the best articles I've read describing the issues and thought processes around the complexities of structuring css. But the suggested conclusions are exactly where I start to have problems. Take this recommendation for example:

  .align-left {
    text-align: left;
  }

This is a very reusable class, of course, because it is literally just css but with a different name. But that's what always ends up happening. The lowest common denominator for reusability in css is so low, that you often end up with ridiculously simple classes like this, or close, basically re-inventing css with a different syntax. The new challenge becomes learning this new language and how to compose it.

The core issue with CSS is that it has divergent architectural characteristics simultaneously. On the one hand there are usually a set of extremely re-usable primitives: btn, normal-text, overlay, card, etc. Then very quickly, we get higher-level components/styles that are extremely not re-usable: order-form, contact-page, etc. And other stuff in between. Applying the same structural models to all of it will cause sub-optimality at some level.

To address this, I've found that applying different models to different aspects of the css most beneficial. Basically having a mix of both utility css, and semantic css. Low-level, highly re-usable components are defined in a utility fashion so that font-sizes, colors and other things are consistent throughout the site. And complex, non-reusable high-level components that compose primitives, and other custom non-reusable css, to define the top-level components. When the need for sharing common css arises, those can be abstracted out into utility stuff, but part of the goal is to keep the utility part small so that people don't have to learn an entirely new language.

[1] https://adamwathan.me/css-utility-classes-and-separation-of-...