Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.
Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue.
[0] When it comes to CSS—of course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change.
You eventually end up with a rebranding and along with that some sort of UI refactoring.
This approach is incredibly valuable when building something that won't change drastically when you are changing those tokens.
A good first step is to have your color palette in your design tool of choice consistent with the variable names used in CSS.
> But I suspect it also can stiffle innovation.
Like any system: it can both be empowering or the opposite.
It's a tough balancing act. Let's say you're Adobe, and you want Photoshop/Illustrator/InDesign to feel like a single family of products across web/iOS/iPadOS/Windows: where do you want to let feature teams innovate, and where must they adhere to the system so users can navigate seamlessly across these products and platforms?