This is not true. The only reason software needs constant updates is because new features are constantly being added to stay competitive. If you stop adding features, in theory you will eventually run out of bugs to fix as well.
The problem is feature creep. Software doesn't "decay," and thus does not need infinite maintenance.
Software assumes that there exists specific hardware, operating systems, and services underlying it to keep operating. If you try to turn on a 5-year old android phone, you will find that your apps probably don't work (because of service changes for example), but also can't be upgraded because the latest versions don't work with your old version of android, and your android can't be upgraded because the latest versions don't have device drivers for your phone hardware. You're SOL.
So, to have a 100-year software, you need commodity components from the top down, that continue to be maintained for the same length of time. And it all probably needs to be 100% open source. Otherwise, you have perishable software.
You can have a program with 1 purpose and no added features experience a variety of critical flaws over a period of 30 years. While there might not be a 'decay' as such, there definitely is new understanding and as such new attack vectors.
The same goes for the stuff the software runs on top of. Your program might be programmed just fine, but if the CPU it was programmed on no longer exists and the replacement CPU has new features that allow that program to be exploited in new ways, that is still a flaw of the software. It couldn't have been foreseen, but it still happens.
The concept dat the things we build are frozen in time never holds up. The difference with software vs 'other things' is that it doesn't degrade or get 'used up' (as you wrote yourself). But the things around it do and as you cannot write programs against all possible future contexts, it will need maintenance for as long as it is in use (from a software perspective - a business thinks differently about that, especially risk analysts).
Has it been extended? Yes. And some extensions can be seen as borderline required. But I'm not unconvinced that one of the biggest factors in this is that he tried to make it stable. And showed great restraint in what requirements to go after.
This is not to say things couldn't have been done better. But I love that all of my documents still compile just fine. Modern practices? Nope.
New features... or just a redesign of the UI to make it look "fresh"
A 28kbaud modem, analogue phone, consumer film camera or virtually any electronic good that uses valves: if they were designed to last 100 years surely you agree that would that be a waste of resources?
Think of 50 technological objects in the home from say 75 years ago. Now look at the models or brands that were then designed to be still useful now. Was the extra cost worthwhile or did the object become obsolete for a good reason? What would the maintenance costs for those objects be? Go to a estate sale of someone that bought quality technology items and kept them: review how many of them would be obsolete (because they are just not useful, not maintainable, inefficient, time wasting, irrelevant, dangerous, or otherwise useless for fair reasons).
Even worse, expensive well designed goods (e.g. jackets) that while still useful are thrown away because no one wants them... Human capriciousness needs to be part of the compromises we make when designing goods.
What are we talking about here? Asking people to not write bugs?
I think of it like a car where parts can be replaced if those parts have an issue, but the designs of the connectors stays the same, and replacements are available. A 100-year car isn't one that requires no maintenance for 100 years; it is one that can be maintained, and replacement parts can be acquired, and it will still continue working.
If a car depends on a remote server, such that the car stops operating when the remote server is shut down, then that car is perishable.
Unless the car is built primarily with 3rd-party parts (from manufacturers like Bosch, Brembo, etc) - which is something that consumers usually hold against a car, like how many people are upset that the new Toyota Supra is actually a BMW - then the problem is almost completely analogous to the shutting down of remote servers; if the manufacturer goes defunct or can no longer make a profit by continuing service, the car’s life has perished.
And in fact, the only way to avoid this is super conglomerates and monopolies - Lamborghini parts should always be available, because they come from the Audi parts bin, which comes from the Volkswagen parts bin.
My 2017 Volvo XC 90 somehow begins to casually malfunction whenever I drive it beyond a few service warnings. The car is HEAVILY software dependent. It can technically drive itself and park itself too. This behavior somehow disappears once the dealer performs software updates. It's pretty strange, and I worry it's a ticking time bomb for when I reach the end of my warranty on the car.
There is also something missing from my metaphor which is that even when the parts no longer exist, the car can still continue to run until it breaks down, rather than being remotely killed due to an external signal separated from the car itself (e.g. servers shutting down and triggering some switch in the code).
Note I said bugs, not add new features, you can charge for features, but if I don't want the feature you should still fix the bug.
I have been thinking for years that as a society, we need 100-year products. It would be a global good to counteract the local incentives for producing perishable software.
However, over time I have realized that there are legitimately unforeseen circumstances that come up - for example, the general realization of the need for stricter security around logins (e.g. two-factor authentication). Maybe a 10 year time window is realistic for now.
In the meantime, requiring expiration days would go a long way towards calling out how perishable our devices and software are.