I believe you are conflating a few things under wrong categories: something that only has a single "stream" of releases (for instance a web application, but it could be anything, an API or a desktop/phone application) needs to only communicate where it's at for "debugging" purposes (talking about a feature/bug from previous releases, referring to the problem a customer has...). A calendar version works fine as long as it matches the release cadence (eg. do you do 100s of releases a day? might need more than a date) and allows easy referentiality.

If you strictly maintain a single API version and expect all users to stay in sync, calendar versioning works there too: it is has different meaning from numbers in SemVer, but it is semantic in that it informs the user of when the changes were introduced in your stream of releases.

Just like it does make sense to use SemVer for desktop software you have paying customers for 2.1 and 3.0.

Your versioning should have a goal and fulfill that goal. Your attempt to shoehorn software types into versioning schemes makes no sense, even if I am with you that SemVer can drive good API development practices if applied to the letter (or can result in you quickly getting to 145.14.7 where SemVer did not really help and is likely not suitable for your product release cadence).

If you're getting to a semver of 145.14.7 with Semver then sack your API designer.

Remember the major version bumps when it is not backward compatible. New functionality can be backward compatible.

You can keep older semver APIs working with endpoints that support upgrading the older format to the newer internally, which allows you to enable things like sunsetting API versions to provide automated upgrade notifications.

All I'm saying is that user version numbers are more a marketing exercise than anything logical.