Somehow, we've managed to take that natural feature away.
That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever.
Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way.
Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay!
Obviously we can still make sure great consideration is made both before adding something new and before removing it.
There’s no getting away from the balancing act between change and conservation.
There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation.
The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1]
But with time and complexity, dependencies started to expand.
One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation.
The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts.
At runtime.
Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle.
(Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.)
But as bits of that infrastructure fall apart, you'll find that digital does in fact decay.
________________________________
Notes:
1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....