Our experience with Backbone, was that the majority of code in your models and views is about keeping the two in sync. i.e. if a field on a model changes, how to update the element that the view controls in the most efficient possible way. We experimented with several methods of handling data-binding (two-way at the time) for us, but weren't satisfied with any of them.
I was building a particularly complicated content editor with Backbone, and was getting frustrated. So I spent the next morning learning React, then re-implemented the whole thing that afternoon. All the complexities I was grappling with disappeared. Obviously there were new challenges to replace the old ones, but we've found it's much easier for someone to pick up work on a React project than it ever was with Backbone.
To start with we were using Backbone models with React views, but now we just use a flux implementation (Fluxxor), and don't bother with much else. Our client-side JS stack is essentially React, Immutable, Fluxxor, superagent, moment and mousetrap, with only the first three being core ingredients.
This repeats my experience too. Backbone gets nasty too soon: nested entities, pagination, invalidation, caching have to be ad-hoc ugly solutions because Backbone is just too rigid where it better be flexible, and too flexible where it should have been rigid.
We gradually moved from Backbone to React+Backbone, and finally to React+Flux. It's been amazing since.
It's my (perhaps flawed) understanding that React deals only with the "view" part of an app, and that you can use Backbone and React concurrently.
Could you elaborate on what you call "Backbone soup" and how React helps solve this problem?