For Tailwind in particular, it’s easier to understand the benefit if you consider the three main problems it solves: 1. Naming things “semantically” is a giant

For Tailwind in particular, it’s easier to understand the benefit if you consider the three main problems it solves: 1. Naming things “semantically” is a giant pain. Sure “user-card” is easy enough, but when you have to start giving names to all the little bits of the user card it quickly becomes absurd. Yeah you can use child selectors and stuff to ease that a little but then you’re basically re-writing your HTML in CSS. Tailwind’s approach is to say “have a UserCard.{html,vue,js} component and move on”. 2. Most codebases have multiple people working on them, and those people are often not CSS experts. It is very common to end up with giant stylesheets that only grow with time, because people are too scared to ever remove or change things in case it breaks something seemingly unrelated. Utility frameworks (and other modern approaches like styled components) keep the styles directly attached to the HTML being styled. You can make any change you like, safe in the knowledge that you are only affecting the thing in front of you. 3. It pushes you into a design system. Sure this is achievable through Sass/CSS variables, but for Tailwind it’s right there with a sensible default out of the box, and easily configured if you need something different. I think the important thing is, Tailwind doesn’t enable you to do anything you can’t do by writing well structured CSS, because ultimately it is just CSS. However, people aren’t perfect, and I believe that Tailwind does a genuinely good job of helping people avoid common footguns. If your team is largely composed of CSS wizards who are fine to carry on as normal, that’s great, you probably won’t get much out of Tailwind. But for a lot of us, the price of remembering some (very consistent, to be fair) shorthand class names is well worth not wasting hours battling the cascade and suchlike.