And let’s be real, if a system is non-legacy it’s likely being completely rewritten every 5-10 years anyway. Not many active codebases have 10 year old code still running.
A few years back we started an effort to rewrite some old C code into a modern system with formal proofs of correctness. That was given up because the new improved process turned out to be 3x more expensive to write new code vs new code in the old process. (formal proofs were the reason to use the new process, but not the reason it was 3x more expensive. I'm not allowed to comment beyond this so don't ask...)
But all of them still contain crucial central parts that have been created decades ago, and famously have not been redone from scratch in their history, unlike, say, Windows or vim.
I don't see what is the principal difference between these pieces of software, and some COBOL-based accounting packages still doing heavy lifting in s bank, while being actively maintained and even receiving new features.
It's the old systems that "just work" until they don't. Where they run on old hardware, and the compiler is possibly on something even older. You can't port them to a new system because you may not have a compiler or even the source code. Or the source code is heavily dependent on the original physical hardware. Maybe it runs in a VM, if it was on an IBM mainframe it probably does. But that doesn't fix the problem of old code that can't be easily altered at this point in time.
I like Michael Feathers' definition of legacy code being code without tests. But it's not just tests, it's comprehensibility and (to a lesser extent) portability. Tests help to make a system comprehensible and portable. Since architecting for testing requires better modularity which makes things both more portable and more comprehensible in most cases. Portability means proper abstraction over the hardware or other things so that the core logic is separable. Imagine if the IRS's tax system were written in this way, where the hard-to-port part would be the interface with databases and networks, but the core part would be easily portable (or more easily portable) to another OS because it'd be properly separated. We could port that core to another system and change how it gets called more easily. But if you tied your software to a specific DB or a specific storage medium (like it has to be a tape drive, or something that behaves like one) you've reduced portability, and created the start of a legacy system.
It is if you're on the most recent working version (3.6).
System being completely rewritten - I can't agree on that one either. Some, in some companies do, most don't. I personally manage quite a few of those and there isn't budget for costly migration experiments if things work. Working in one of the biggest global banks in Switzerland. What works is if ie OS/browser that is absolutely required isn't supported anymore and there is no way around it.
There are very few cases where the approach 'if it isn't broken don't fix it' isn't the best approach for the company. But good luck trying to explain it to devs/teams who want to try new things (basically at the cost of employer, I don't blame them but it is what it is).