Ugh.
The expectation that once you've made something you can't expect it to keep working without endless catchup, attitudes like this one, are why I have completely given up making software for fun or to solve noncommercial problems for myself and others.
I'm not the only one.
I don't think there is a single type of item in the world for which you could expect it to keep existing indefinitely without maintenance. Machines rust, wood degrades, paintings need restoring every few centuries. And even when properly stored in controlled atmosphere etc, books from a few centuries ago are almost unreadable because the language has changed so much since then (see https://web.cn.edu/kwheeler/diagram_4english.html for example).
Everything in this world needs constant maintenance or it breaks down. Why would you expect software to be any different?
I have books up to 500 years old that are perfectly readable. I have programs I wrote single digit years ago that I'd need to give up a couple of days just to find out if I can get their build chain back and dig them out of dependency hell. Not worth it to buy, at best, a few years before I get to repeat the experience. Restoring and rebuilding old physical things is also far more rewarding because when I do it properly I never have to do it again.
I've owned physical objects that were worthless a few months (cheap throwaway), and have also worked on code that was over 5 decades old and still compiled just fine. If you construct the software with care it is entirely feasible to have something that you can run several decades from now, but that does mean that you shouldn't use dependencies which might disappear in that time. Curl or sqlite are probably fine, a dependency with a single maintainer is probably not fine. Network dependencies on DNS or NTP are probably fine, depending on the API of some 1-year old startup is almost certainly not fine.
Machines rusting and painting needing restoration is because they oxidize. Wood does not magically degrade, it decomposes. These are physical phenomena confined to the physical world.
Your example of the book being unreadable because people's language changed, that is a closer example but even that falls short because language is a human to human communication pathway. We have to spend literal years training people to understand it, it is inherently chaotic and messy.
Software is math, it is engineered. We don't wake up to find that suddenly the coefficient of friction is different and now our tires fail to grip the road. Or more to the point, that our speed and feed calculators are now trash and will crash the endmill into material ruining the machine and part.
Computers and their ability to run or not run software after and update is completely in the control of the people programing the updates. The reason so much software fails is because either A. It was not well designed to begin with or B. the people creating the update did not design it well.
Likewise hardware architectures change, and it’s absurd to assert machine code from the Eniac must run on every architecture, as well as every variation of every machine ever made on every future hardware in perpetuity. There are to this point many preservation efforts that create emulators that run on modern hardware or reference virtual machines that can be carried forward. But to expect this to be done in situ everywhere all the time for everything is on the surface absurd and unreasonable to an extreme.
Edit: the Eniac didn’t have machine code, but switches and wiring - even more to my point. While it’s still just math and logic, it’s not reasonable to carry forward all software configurations of the machine.