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"