Legacy code isn't always bad. All code becomes legacy code.

Poor legacy code is a liability, and legacy code that leads to suboptimal technical situations (e.g. using C++ in 2009) is a pain.

What's wrong with using C++ in 2009?

It gives up all possible safety for performance gains that haven't mattered on the desktop for years. "volatile" is not enough of a memory model to write portable threaded code for I/O bound multicore machines. And it's missing an awful lot of modern conveniences that are painful or unreliable without language support: AOP, closures, currying, invariants, reflection, serialization, remoting, extensible syntax.

Echoing the commenter above, people writing C++ in 2009 are laughing all the way to the bank.

I don't know about laughing all the way to the bank, but I would probably have more difficulty writing machinery control code in anything other than C++

All legacy code is a liability, and all code is legacy.

To me "legacy" connotes flawed, not merely old. If a rewrite would end up slightly modernized but basically the same, what you have is an investment. If a rewrite would end up completely different because the old version doesn't meet the current requirements, what you have is a legacy problem.

You are distinguishing between "legacy" and "legacy problem" and thus rendering your own opening 'thesis as moot.

Sorry, what I was trying to get across is that I don't expect to hear "legacy" unless there's a problem.