I'm not sure that I agree with the article... the view logic DSL that is JSX isn't bad at all, it couples your render structure with your components. Beyond this, you can have simpler dumb, static-rendering components with react.
What really strikes the chord with me is the Redux pattern for control flow... your state is driven by action creators and dispatchers. With a single state tree, broken up as appropriate, it works very well, even for moderately complex applications.
As far as react's size, I've got a stand alone control (may as well be an application) with a payload (min + gz) of 16.2kb [1] for a date picker control. It's using preact, preact-compat, redux and a few other pieces. So it can be lighter still, still using JSX.
Another lesson learned is to structure by feature, not file type... by coupling your render layer with your components, as opposed to separate templates, you don't have a complicated DSL to learn the behaviors of, but a simple prop="string" vs prop={JsLogic()} ... same for inline js {{js}} vs whatever weird dsl is used for iteration, conditions, etc... in React and its' ilk, it's all JS. Even JSX is a DSL that translates directly to JS.
I don't know enough about Catberry to comment, but having worked in web applications for two decades with I lose count of how many rendering systems, frameworks, toolkits, and techniques over the years... React (or preact) and Redux is the first time I've experienced a set of tools that feels like the "right way" to do it... now, Webpoack, Babel, and the configuration mess is a different story, but once that's setup, it's pretty smooth sailing.
[1] http://tracker1.github.io/md-datepicker/ (note demo isn't gzipped payload)
Correction, when ASP.Net came out with its' server-side lifecycle I was enthusiastic, but quickly learned how much of an issue that was in integrating JS responsiveness client-side.