For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline.
Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
And even if you want to centralize state, with local state it's not even that hard to do yourself (put it at the top or in a few small containers, push everything down, have callbacks that bubble it back up. A bit verbose, but easy to abstract out, though you'll end up with something close to redux).
The main issue with all of this is that 95% of the stuff you read about all of it on the internet is wrong, namely because building a real app and maintaining it is very different from making a toy project or a Silicon Valley style MVP in 6 months. People optimize for the later, then when they start maintaining their app its shit. So all the info on the net helping you to reduce boilerplate, optimize for the first version, etc, is just hurting you (but its almost everything you find online)
Abramov has been beating this drum for a long time: there really are a lot of React apps that use Redux but really don't gain anything from it.
We also use TypeScript though, so this more OO-style approach felt more natural. It's not particularly verbose (in the context of interfaces and static types, so YMMV) and it's been extremely easy to work with so far.