I understand the idea but I still think the BEM methodology is better than this approach.

I disagree. Using something like ReactCSS, all the code related to a component is in the same file. I don't have to switch between HTML, JS, and CSS files just to edit some small part of my app.

I'm not sure that trying to keep everything in one file is necessarily a great argument. Optimizing for not having to open files doesn't seem like the best thing to optimize for. Even many of the react+inline styles examples include putting variables and other patterns into external files. Language (i18n) strings could be another external dependency. Data model, controllers, and routing are other good examples. (Rarely (if ever) have I seen an MVC framework that doesn't separate things into separate files.)

It's more conceptual than keeping everything in one file. I want to be able to see everything related to a component without looking at anything else, and to be able to easily change its styling in the same way I change its structure or behavior (at least with React). You can technically do this by creating a separate CSS file for every component, but the problem is your CSS has no context about your component, and so you end up doing all kinds of shuffling with classes to get things to display the way you want them to. This is a much more elegant solution, in my opinion.

BEM is a clever naming strategy to deal with the problems of a medium-to-large CSS codebase. Why put up with it in the first place?

Component-orientation and both exist to mend the problems of global CSS. If you use BEM in React you will usually have a one-to-one relationship between BEM component classes and React components. RaisedButton component has a .RaisedButton class, Icon has .Icon, etc.

We do this Imho this is just "better" management of the same problem