Excel is great until you need to fix/extend an app that is now integral to all company operations that was made 20 years ago by that guy in sales that was good at computers and has long left.
It does have something to do with it in the sense that it locks code in a proprietary format that does not allow code traceability and source co trol, and does not favor best practices like code comments and commit comments. That does make maintenance harder.
It just occurred to me that the situation is isomorphic to any runtime environment. I cannot imagine transplanting a shell script, C program, Java program (OK, maybe except for a Java program), Win32 app (OK, maybe that also), or a web-app from 20 years ago onto a modern version of the runtime and expect it to work without any major changes or fixes to account for the inevitable cases where the outside world simply decided that "we do not do things this way" any more. Cross-site scripting, password strength, political and timezone changes, many of those trip up applications too.
Shell and C should be fine. To be honest any pure computation should be fine. Your interactive HyperCard stack if you get the right emulators would be ok. MAME, sure. But anything depending on the persistence of networked resources will not work. Other than Phil Greenspun all the endpoints have changed. CGI with no external dependencies or Ajax should work except it got pwned along the line.
Except most likely it wasn't bash shell, or maybe it was, but it was written on an HP-UX and never ported to anything else.
Likewise the C code might eventually be written in K&R C still, make assumptions of byte ordering on the MIPS and memory access semantics of workstation it was originally targeted for, and with luck use SGIPro extensions.
Then you realize it's pretty amazing that an app that was built 20 years ago by a non-programmer without any assigned budget fulfilled the needs for so long.