That would be ideal, but in practice, SemVer is frequently broken with technicalities or outright disregard for standards. Look at K8s: still on v1, but there have been countless breaking changes. Their argument is that the core application hasn’t changed its API, it’s all of the parts that go into it to make it useful (Ingress, Service, etc.) that have had breaking changes. This is an absurd argument IMO.
Then there’s Python - which I dearly love - that uses something that looks exactly like SemVer, but isn’t. This is often confusing for newcomers, especially because most libraries use SemVer.
This is one of those things that becomes clearly untrue if you try to apply any amount of rigor to the definition of "just fine".
I have yet to see a single major Python project claiming to use SemVer that didn't occasionally unintentionally violate the promise made by the versioning because you cannot always easily predict whether a change will be incompatible, and, even if you could, people still regularly just make mistakes because people are not perfect. Versioning is hard. Keeping promises about not breaking things is even harder.
That may be good enough for things that don't matter, but it's not good enough for things that matter a lot.
Maybe I'm being too pedantic here, but semver for applications is always going to be broken and driven by marketing. SemVer, for my money, is only applicable realistically to libraries.
Then there’s Python - which I dearly love - that uses something that looks exactly like SemVer, but isn’t. This is often confusing for newcomers, especially because most libraries use SemVer.