I suppose I look at things differently, because I use the BEM/SUIT methodology. There is already a logical one-to-one mapping between most BEM components and React components, so the effort required to change everything would be roughly the same.
The point of using inline styles isn't to be hip: it fixes most problems caused by specificity wars, global selectors, monkey patching, code bloat, dead code, and indeterminism. I agree that there is yet to be an implementation that is perfect, but there are some very smart minds working on this problem at the moment.
Right. So long as you follow sound architectural practices and be careful to not override global selectors, you will achieve most of the benefits of inline styles. https://github.com/postcss/postcss-bem-linter is a godsend.
However:
* Your components will still be spread out among separate files. Button.js, Button.scss. Icon.js, Icon.scss. Just like it doesn't make sense to separate inherently coupled HTML and JS, it doesn't make sense to separate inherently coupled HTML/JS and CSS.
* You have to use two separate programming languages unless your app is simple.
* SASS and LESS can be really problematic. They have ambiguous syntax and are non-standard. There's 9,001 ways to import in LESS. They look like programming languages, but they differ in confusing, bug-prone ways. SASS and LESS's variable resolution are different and confusing. And math is whitespace-sensitive. Yes, whitespace-sensitive math.
* Another build step.
* No easy way to get values statically from CSS files. Instead you have to use comments like "IMPORTANT: keep this value in sync with Button.js!". And if you forget, you will have a difficult-to-debug problem.
The point of using inline styles isn't to be hip: it fixes most problems caused by specificity wars, global selectors, monkey patching, code bloat, dead code, and indeterminism. I agree that there is yet to be an implementation that is perfect, but there are some very smart minds working on this problem at the moment.