It very much depends on how you define "legacy" in this context. Let me give you an example from C and C++. Many C++ programmers call it a bad practice to use C strings in C++ applications, others demand no mixing, while others, in turn, claim that it be sheer and utterly pointless to use any bits of C code because they are old, i.e., "legacy" code. Some go further and avoid using pre-C++X (replace the 'X' with the appropriate number) standard idioms, style--that is syntax, for it's "legacy" style.
Leaving aside performance issues of C++ streams and strings and a few STL peculiarities, it sure is a great practice to have a look at what's inside your so much beloved preprocessor directive
#include <string.h>. If you follow the path to the implementation and find yourself on a unix/linux machine at
/usr/include/string.h (and get libc implementation sources, for example, from gnu.org) and read
strtok.c, I bet you're gonna hear "What a beautiful world" phasing in.
There is, however, a caveat to this prose--namely, deprecated classes and methods. In Java quite a lot of legacy stuff is still accessible from within a recent environment, but if I recall correctly, not everything. In the IB sector, from my own experience, well, not all software is written by good programmers. Lots of graduates had had virtually zero exposure to real-world programming before they started out at an analyst/developer position. But don't generalize this statement. I know lots of folks who employ Java and C# at the core of high-throughput, low-latency environments. I don't agree with them, but well, this is fortunately their business. Had they gone real HFT though, they'd get pushed way behind in the line. But again, easily inferred from this sentence is the assumption (and in many cases the fact) that Java code is highly optimizable. And if you can excel at optimizing, if required, not only fixing this or that, you'd become invaluable as a dev. It's very satisfying by the way to realize how much you have contributed. I'd go for it.