CSS is a different technology for a different complementary purpose to, say, markup or business logic. That's why we have the separation of concerns principle. If business logic is doing CSS's work, design changes MESS with the business logic, which is undesirable for obvious reasons.
By saying "CSS is more a separation of technology, than a separation of concerns" you are saying "CSS is more a separation of concerns, than a separation of concerns" or possibly "CSS is more a separation of technology, than a separation of technology".
As for the modularity concept, that doesn't have to flout or adhere to "separation of concerns". That's just a different thing.
I'm not familiar with React. I tried reading a primer on it and got really bored. Couldn't imagine how it would change my work. Then again, I'm mostly a UX designer who works with code rather than an "engineer" focused on abstraction and performance.
Just to clarify, the "layout versus presentation" thing isn't just for its own sake. It's to avoid having to implement design changes in two places (the CSS and the template/backend). By using template logic and classes (CSS hooks) this would be inevitable.
As for the ugliness of the CSS, well... that's what the CSS that works for the purpose looks like. Function over form. I'd recommend _adding a comment_ if you want developers to grok the code.
I must say I find it odd that you think transparency for fellow developers is _more_ important than the actual purpose of the code. Your convenience in maintaining the product cannot be more important than the product itself, surely?
