The problem is that it makes a branch hell for devs, and makes documentation harder. You now have 3 levels of branches that have to be maintained:
X-1.Y.z
X-1.Y-1.z
X-1.Y-2.z
X.Y
X.Y-1.z
X.Y-2.z
X+1.Y
Plus, in the Moodle community particularly, this is probably of limited value. Most larger Moodle installs don't want mid-stream new features. Not only do they still have to test everything, but they have to update documentation, and training, etc. The marginal cost to test all their plugins to make sure they are still working in minimum when they only plan on updating once or twice a year anyways.
The other thing this does is it makes it harder to jump to the X+1 release. Right now we move in small, steady jumps. Very few things break between each release, so the work is minimal. What would almost certainly happen is that people would never leave the X release to the X+1 because it will just be too much work. We saw that with 1.9, and you see it in other projects. The current system does a better job at keeping sites more current.
The thing is, current Moodle numbering system already tells you that, when Y changes, they can't garantee that your plugins will continue to work, you have to test them, because there are almost always API changes in those releases. The only thing that really added confusion to the mix was the choice to go to 3.0 instead of 2.10. Because there are no plans for a major rework in the pipeline, it was decided that it was less cumbersome to let it roll forward to 3.0, and I agree. There is another way to look at it - The next major version is so different from 2.0, that it deserves it be a new major release, even though we have gotten there via evolution.
While I get the benefits of semantic versioning, as both a plugin dev and a large site admin, I think it would just add workload and confusion with very little upside.
