Actually, using props instead of state is a pretty common thing to do - it's how redux integrates with React [1]
I've certainly seen a number of people in the community who insist that you _must_ keep everything in Redux, and that you should probably only use functional components along with that. I can understand why people might want to do that, as it means there's more state in the Redux store for traceability, UI output becomes highly predictable, etc. However, I would say that approach is too dogmatic and over-opinionated. It's a valid choice if you want to go there, but not something that should be enforced across the ecosystem or taught to learners. Class components, functional components, Redux store state, and React component state are all tools with specific use cases, and throwing any of them away is unnecessarily limiting your toolbox.
(Might not have been exactly what you were asking, but given how frequently this topic comes up, I wanted to put that clarification out there.)
Reducers are composable, so you can actually end up with pretty clean code in large codebases
Most (presentational) components will load its needed data from a container component (through connect(), or other higher order components we developed). So for example, a given `user` object, could have its data in a chat component, or an analytics view, or a settings profile. The reducers aren't generally concerned with how the data is used, just that its available to anyone who asks.
As far as localized state goes (like a form), we took a page from reduxForm (and we use reduxForm) - if there were times we needed to use setState a lot (for example, we had a query builder and chart components), we built a higher order component (like connect), where you would pass the props you need, and that component would figure out how to query it and make it available in the redux state. Again this meant you could create a "query object" from one component, that was theoretically available to any other component (as part of the Redux tree), if they asked.
All in all, I never considered any sort of 1:1 relationship between state and components. I had state, and the components decided what state they needed and rendered themselves appropriately. This was a fairly complex SPA that had real time chat, analytics and CRM-like features, there were 100s of components.
Our codebase was far more robust from the Angular version we had rewritten it from a year ago (a component crashing didn't bring down the whole app), and the concerns for every component tended to be self-discoverable (we were able to hire interns to start hacking on it within 2-3 days, after they wrapped their head around redux). I'll admit it took me sometime to understand the benefits of Redux, and there was a lot of ugly boilerplate until we started using higher order components, however "brittle" and "messy" is the last words I'd use to describe the codebase.
Think of the classic case showcase of redux being used with immutable structures to implement a page-wide undo easily. There's a certain amount of state that could be burried deep in components that doesn't need to be in the global redux store.
Sure, your undo might not now be an exact representation of the historical state of the page, but the state that counts is still re-created, and that's the state that you can decide to put into redux.
Redux makes available state that is required globally, like the contents of your todo list or other properties that must persist as you navigate a web app. Components will store their own state for their specific requirements.
I suggest reading up on redux use cases to find out more before dismissing it entirely.