> If your users have the ability to actively choose what version of your software they're using, it works.

I don't think SemVer is about choosing which version to use; it's about being able to plan the impact of upgrades. So the only requirement really is for your users to be able to actively choose when to upgrade.

Which does still mean that breaking your API should be avoided: all a major version release does is communicating to your users that it is likely to be more work than a non-major upgrade, not actually lessen the work.

See also https://vincenttunru.com/semver-explained

I also don't buy this:

> Semver throws a complexity wrench in what would otherwise be straight-forward automated releases.

SemVer is part of proper communication with your users. So is a proper changelog that explains how a release will impact them. If you have a properly updated changelog, defining the scope of the version upgrade is trivial; if not, you have the task of updating the changelog as a wrench in your release anyway.