Having tests is not a panacea. There's no guarantee that any of the tests are automatically well-written - they could be too narrow in scope, overly brittle, or be so numerous that each minor change requires hours of automated testing, making progress a huge chore.
That's not to say you can even run, let alone compile some legacy code without a large amount of effort. That's the whole point of the term, that they rely on obsolete, unsupported or just ancient OS, hardware or platform, often requiring emulation, special development environment.
Redefining it to mean "code without tests" just confuses things.
To me "legacy" means when you are stuck with something outdated. Code is not legacy just because it is old, it is legacy if it can't be adapted to changing requirements. For example old mainframe systems where the source code has been lost.
Code can be brand new and on the most fashionable platform, but if it is undocumented and unmaintainable and the original developer is unavailable - then you have legacy code. Because you are stuck with it and can't keep it updated.
If on the other hand the Turbo Pascal program runs fine and you have test coverage which allows you to refactor and adapt to changing requirements - what is the problem? And if you want to port to a more modern environment or platform you can do that with low risk.
Of course tests can be badly written, that goes without saying. Nothing is a panacea - not even microservices in Go!
That's not to say you can even run, let alone compile some legacy code without a large amount of effort. That's the whole point of the term, that they rely on obsolete, unsupported or just ancient OS, hardware or platform, often requiring emulation, special development environment.
Redefining it to mean "code without tests" just confuses things.