Is this going to be part of the 1.0 release schedule, then? It seems ridiculously breaking when they're only 20 days from stable!
In fact, as we approach the alpha, I expect several frantic last-minute breaking changes as people attempt to beat the buzzer.
That allows them to tell people that, yes, they can depend on the fact that the language and API will not change from, say, 1.2 to 1.3. And that they will continue to support it for the foreseeable future. But I imagine that eventually they will want to make breaking changes, as they certainly won't get everything completely right with 1.0. But that will be clearly marked as an entirely new version.
More info:
Which lets us relive the fun times of eg. Dlang 2.0 release or Py3k
But in an attempt to answer your question, I see Rust development as an application of simulated annealing (https://en.wikipedia.org/wiki/Simulated_annealing). In all honesty, we could probably spend another two years toying around and seeking a "more optimal" solution... but I personally agree with the devs that we have reached a point where the value of seeking backwards-incompatible solutions no longer justifies the time spent unable to cultivate a growing stable of third-party libraries.
That said, Rust won't be standing still post-1.0. Not even close. There are lots of language improvements that will be arriving backwards-compatibly in the coming year (e.g. improvements to dynamically-sized types, improvements to closure type inference, various improvements to the trait system like negative bounds, and so on.). Longer-term, I expect Rust to look into a design for higher-kinded types, which could eventually allow for generic monads in the vein of Haskell (though this should be considered a very far-future goal, perhaps even worthy of a Rust 2.0).
Pushing it out before we think it is ready just because some people want to use it will result in stabilising a suboptimal language and so trade-off the long-term experience for the 5 years (or 5 decades?) for some short-term gratification.