My solution to this isn't "never update anything", but rather "never version anything". People can choose to stick to the bits they originally got, which is perfectly fine, or they can switch to the current "live" one. As a developer I'm only ever building and maintaining the latest source.
That's valid under semver.
The crazy diagrams show what happens when you want to support lots of old versions.
I have semver stuff at work where I only maintain the latest version. Bugfixes bump the patch version, adding a feature bumps minor, removing a feature bumps major.
I don't make any special effort to bump or avoid bumping anything. It gives me a rough idea of whether a given version has new stuff in it (x.1.0 or x.2.0) or is just a bugfix (x.0.1 or x.1.1)
Dependency hell has nothing to do with how you label your versions and everything to do with how much you want to annoy users by breaking whatever you like vs annoy yourself by taking the time to set stable APIs and hold compatibility backwards and forwards.
Semver vs. Git commit hashes vs. "just one number" vs. web browser versioning vs. "just timestamp" is all just different labels on the same soupcans.
I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.
Even if you go through a deprecation cycle, you're still going to eventually have a build N with feature X, and build N+1 without feature X. That's a breaking change.
You now have no way to indicate that you know your changes are breaking.
I've noticed (more frequently) npm packages quickly climbing in versions (1-17 in a couple years) but at least it's painfully obvious.
On the other hand, the longer you wait to update, the worse it gets. Updating more frequently you can suss out packages moving quickly vs slowly vs not at all and address the problem before you're in update paralysis