This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
It's not possible to flash misinformation with normal front ends before React, without going to extreme extra effort to enable such misbehavior. Whereas with React, the easiest programming path is the user hostile path. And React is adopted only to make it "easier" on programmers.
Nothing about React specifically enables that kind of design.
jQuery, Backbone, Angular, etc.. You can / did do this in other frameworks prior to React.
I think, from reading your comments, you think client side routing and single page applications equals React. That's... an interesting take.
If my irrational hatred has a better target than the term "React" I would like to know it. I do despise the usability of nearly every SPA I have used. It is perhaps possible to program an SPA so that the deficiencies are not noticed, which is great, but that does not appear to be the norm nor is it made easy by SPA frameworks.
You can choose to have higher latency for the initial request and just display static HTML. Or if you want to load content on demand, then you do have to deal with what happens before anything loads, but I don't think that's the fault of React. Any framework which does this is going to have the same problem that needs to be solved.
Similarly to React "breaking" the back button. If you want user interaction without another page load, you have to deal with the consequences such as needing to track page history more explicitly than you might have otherwise. But that's because the dev chose to change the page content without moving to a new URL, not because that was implemented using React.
