If you are building a totally generic CSS library to use on a bunch of independent sites, then sure... utility first. But the main reason I think semantic CSS

If you are building a totally generic CSS library to use on a bunch of independent sites, then sure... utility first. But the main reason I think semantic CSS is important has nothing to do with anything technical. CSS is not just a technical contract with the browser, it is the place where your organization’s design language is made manifest. If your pages match what’s in your designers’ mockups, that’s good. But if your CSS matches what’s in your designers’ heads that’s way, way better. What that means is that “configurability” and “flexibility” and “composition” are anti-patterns. Being able to do anything is bad. The goal is the opposite: almost everything should be impossible to do. The goal is that you can only do things that make sense within the design system. That means making something that’s technically quite useless, but just barely can do the things your designers want to do. The same applies to component names and arguments. That’s the other place where the design system contract becomes real. So, if you’re a freelancer than yes, go utility-first. But if you work on one app day in and day out then you’re playing a different game with different goals.