0.x.x makes sense if you explicitly keep a "the ABI is fluid and will break at any time" rule while using it. It basically means that no downstream project can consume a 0.x.x release—which makes sense. 0.x.x is an exploratory phase, and should be passed through as quickly as possible. 1.x.x is then the first "ABI contract": the point at which you can make a call to the project as a library, and know that that call's semantics won't change or break throughout the 1.x.x series.
(You could determine something like this mechanically pretty easily... if your platform had anything like "ABI specification files", the way many platforms have "dependency specification files." 1.0.0 would then be the first time you generated an ABI "lock file", that would then be used by your toolchain to fail builds that violate it across the 1.x.x series. To delete-and-regenerate the ABI lockfile would be to bump the major version.)
The real problem, though, is that many projects are too big to have a single version sum them up. People need to break components down along stability boundaries—places where rate-of-change changes—and then give versions to those components. NPM libraries are a sort-of-good example of this, though I think there might be better.
This kind of made sense with React as even with this release they were struggling to decide if `context` should be public at all, what shape a "renderable" component should have, etc. Since they've finally decided on these issues with this release, they wouldn't have been able to release it as another v0.x with a straight face.
(You could determine something like this mechanically pretty easily... if your platform had anything like "ABI specification files", the way many platforms have "dependency specification files." 1.0.0 would then be the first time you generated an ABI "lock file", that would then be used by your toolchain to fail builds that violate it across the 1.x.x series. To delete-and-regenerate the ABI lockfile would be to bump the major version.)
The real problem, though, is that many projects are too big to have a single version sum them up. People need to break components down along stability boundaries—places where rate-of-change changes—and then give versions to those components. NPM libraries are a sort-of-good example of this, though I think there might be better.