This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications.
As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a single page (but still want easy, clean dynamic behavior from React). There are serious applications that are single-page, but don't use a formal router because their application doesn't decompose into "routes". And there are applications --- not enough of them, if you ask me --- that just write their own routers, because 98% of what you need for a router can be accomplished in ~20 lines of code.
It's a similar story with Flux and Redux. Dan Abramov has been trying to convince people for years to start with just props and state and resist the urge to introduce a Redux dep before it's actually needed. He's not saying that to ease the learning curve. He's saying it because a lot of those apps will never need or benefit from Redux. For a lot of applications, Redux isn't worth the trouble. Moreover, just like with routers, the Flux pattern started with an idea about how to structure code, and morphed into a library dep. But Flux isn't about libraries! It's about code structure. It is not only possible but probably easier to structure your data in a Flux pattern without introducing Redux. The original Flux "library" was just EventEmitter.
It is in fact not fair to compare the API turnover for Angular to vanilla React plus two optional ecosystem components that aren't actually part of React. But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.