React is trying to turn the world pristinely functional. That's what passing the functions down is about, and the only reason we would ever go through these motions. The only single issue with using event selectors is if you change your HTML. That's precisely what you are referring to and what core React contributor, Sebastian Markbage, describes here at 20 minutes 4 seconds of this video: https://www.youtube.com/watch?v=4anAwXYqLG8#t=20m4s. What he fails to mention is React has a similar issue: if you're passing down event handler functions, intermediary components could change or be added, and you could forget to pass down the function for one "link" in the chain. In both cases, event handlers suffer from the content/structure changing. The pitch for explicitness--which overall i agree with--doesn't hold up that well with traditional DOM event listeners in this case. It doesn't further Facebook's grand "Functional Mission," which I also agree is a smart initiative, which is why they are dogmatically pushing for such things, but I think, for the foreseeable future, event selectors is an acceptable bit of "sugar" if you will. We don't need to drink all the Facebook functional React cool aid, at least not all at once ;).
So given all the extra boilerplate required by passing functions down vs. event selectors, using event selectors is a clear winner--for every case except one: when for whatever reason you just like to be able to look at your HTML and immediately know what event handlers are bound to it. That can be appealing in mobile apps and components that have less event handlers associated with them, especially when the event handler is defined on the component that implements it (rather than needing to be passed down perhaps from several ancestors).
The real problemcurrently being solved by React et al has more to do with the passing down of actual data, not event handler functions--you bind the event handler via a selector, it's gonna work, and it's gonna have the appropriate state and props bound to it; done. I think if you really look at the problem just in terms of events, you'll see it's non-existent compared to the problems associated with being able to reliably trace the flow of "display data" passed as props. At least until Facebook's grand functional master plan unfolds. After all, in functional programming it's all about composing functions of other functions; and I suspect as that plan transpires, it will feel more and more natural to pass functions around--not jerry-rigged as React's current function binding approach feels.
As for the 20k lines--which to be sure, is a hell of a lot..kudos--clearly you're stating that as a badge of honor--so you probably agree you're in a minority group of developers, correct. The truth is the majority of developers and apps are a lot smaller, and will never to get to that size. Not all apps need this (i.e. what Redux et al offers), not all areas of your app need this, and perhaps all this additional upfront work will make it so you don't have the time or resources to grow your app to the point the threshold of complexity that would necessitate this is even crossed! You know, the whole MVP concept of avoiding premature scaling the wrong areas rather than focusing on just getting your core right. To be sure, it's a lot for intermediate (certainly novice) developers to wrap their heads around. Total newbs can practically build an entire money-printing startup with Meteor--those same newbs wouldn't know where to start with React/Redux/etc. As you said, there is a world for both approaches, which "eliminates this division."