React doesn't solve the fundamental problem of either API churn or security issues in browser client code. It may be elegant (I don't think it is) but it is orthogonal to the issue at hand.
Server side MVC and HTML as a transport has a huge number of advantages, not the least that HATEOS "Just Works" without anyone having to think about it, but even if it didn't, I would think that the API churn/security tradeoff would give the development community pause about heavy client-side logic.
React doesn't solve the fundamental problem of either API churn or security issues in browser client code.
I'm not sure what problems you are referring to here, since you don't seem to have defined them anywhere. They sound like they'd be well outside the scope of a library like React, though, which is essentially just a declarative UI rendering tool.
And rendering on the server solves API churn by... having no API at all? Then what do you do once you'd like to add non-browser clients like native apps or an actual API for third parties?
Additionally, I don't see how rendering on the server frees you from thinking about security or setting (and enforcing) proper permissions. All you gain is that the problem is less visible and your entities are obfuscated in chunks of redundant HTML.
In fact, now you may open up new security holes like XSS that you can avoid easily with proper client-side widgets.
Server side MVC and HTML as a transport has a huge number of advantages, not the least that HATEOS "Just Works" without anyone having to think about it, but even if it didn't, I would think that the API churn/security tradeoff would give the development community pause about heavy client-side logic.