That which we call a rose by any other name would smell as sweet.Perhaps it would, if that other name had been chosen from the start.
However, in this case, many projects will have existing code using the earlier conventions.
Moreover, there is a substantial volume of documentation and tutorial blog posts and conference videos and example code repos using those older conventions, all of which has just been invalidated. This isn't just a loss, it is all now actively harmful to new developers adopting React or those trying to update to a newer version, because it's actually misleading.
If a library you're thinking of using in production is as willing to break API compatibility as React is, even if the changes are mostly announced a little way in advance, you should think long and hard about the overheads and instability you're going to incur with a dependency on that library before you adopt it. Move fast and break stuff might work if you're Facebook and thus have both final control over the library in question and effectively unlimited resources to maintain your code base, but it doesn't work very well for the 99.999% of web development projects that don't have those resources available.
To be fair, the React project itself seems to be quite transparent about its development methods. It's not as if they're advertising the library as stable -- it's still clearly shown as a 0.x version, for example. However, a lot of people are jumping on the bandwagon anyway and just hoping for the best, and that's probably not a good idea.
From an API point of view, all of that is what's in a name.