This is why CSS-in-JS solutions outshine utility classes IMO – if you deal with stylesheets directly, it's hard to avoid treating CSS as append-only files that grow linearly with the size of your codebase. With CSS-in-JS, on the other hand, the styles get generated for you, at a size that grows logarithmically to the size of your codebase (style rules of the same value get pulled into their own deduped classes).

Give me an example of that.

Would you mantain .display--block? how? .color--red?

It would be some domain-specific component. Like .product-card. I don't see the examples you've given. Those are so literal, you might as well use inline styles at that point.

That's the problem functional CSS solves: class naming doesn't relay on developer intervention, it's just a translation of the utility.

Product-card is not an utility, that's why it's a problem to maintain such classes.

Changing the saturation of the red and causing it to look messy alongside surrounding elements/images? Or introducing colorblindness concerns elsewhere in the app?

That means two things: you need extra utitilies to have different reds or, you don't mind to adjust the same red that will impact in the rest of the website. As a designer I do this all the time. If my design is complex to the point I would need several reds, then i would use a different value in the class name, like numbers or other options.

Then my workflow for that case would be: create the new color value, compile the CSS, change the class name in those places where I want to use the new red.

The biggest win when using functional css, or css utility classes, is that it is extracted out into a library already, in which case there is nothing to create or maintain (just the downside of messy classnames).

https://tailwindcss.com