1.0 implies API stability, so now is exactly the time they should be prioritising things that potentially change the API going forwards.
Also, is 40kb gzipped really something to lose sleep over? Especially when the mere act of moving from old jQuery/Backbone soup to React reduces the size of my real code by a far greater amount.
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.
Also, is 40kb gzipped really something to lose sleep over? Especially when the mere act of moving from old jQuery/Backbone soup to React reduces the size of my real code by a far greater amount.