Cascade seems like very dangerous thing, that kills all benefits of isolation and BEM philosophy. But OK, it is fare point.
But why BEM is more simple? Examples in your article is much more complicated, than with CSS Modules. In CSS Modules you just forget about selector conflicts and write any selector you want (same feeling like with Autoprefixer, when we just forget prefixes rather than writing a mixins). In BEM you need to use (and think of) special methods and CSS functions.
I still don't get CSS Modules, cascade was a powerful feature of CASCADING style sheets. Like in OO or a mixins an object can inherit properties of another. I don't think that conflicts were a justifiable reason for ditching all that power, css just has to be written with a small amount of care and you don't have conflicts. I know you can compose classes but that's not the same as you end up with a larger css base, that's different from say prototypal inheritance in JS which simply uses memory pointers and doesn't cause bloat.
True, cascade can be dangerous, but omitting it completely seems like a bold move — it's just a use case for cascade is very limited.
BEM is simpler to use because it's just a naming convention and doesn't require any tools (reBEM is just a set of optional helpers). It's also simpler to debug because with css-modules classNames are mixed with generated hashes, and with BEM you can clearly understand who is this className belongs to.
I agree, that BEM can be used without any tools. And it is his benefit. But in this article you use so many tools for them, that CSS Modules become more easy.
Compare:
1. You have helpers in JSX and CSS.
2. With CSS Modules you will have helpers only in JSX ;).
It is for some people. I'm not telling that css-modules are bad in general, it's just nice to have an alternative. I know some people who are talking about css-modules as an ugly hack (though I don't agree with them).