Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.

Eh, I would contend that poorly done semver is still better than date (only) versioning. You can always have date and/or hash as part of the metadata string. As long as you are honest with your team, saying "these are a best-effort to follow semver" it's clear what you are doing. If you are sub-1.0 basically every release is a minor bump anyways.

If my CI says a patch release broke my build, I think "I should figure out why, and report the bug unless it's already reported. This is a debugging task. If I can find time to do it now, it would be contributing back upstream."

If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work.

It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop.

It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?