Legacy can mean anything but based on your 'not so well written' comment I'm going to assume that Legacy means 'bad' or at least 'out of date' technologies and patterns. If the legacy code is good, do not hold back and learn every line of it.
I don't think there are clear enough warnings against the kind of jobs and projects that divert your career and get you stuck in valueless sink holes on this thread to date.
Sports analogy alert: Do you think a line backer in the NFL learns more and becomes more valuable by playing on the team with the worst record or the best? My answer: Not only are they more valuable having played for the best teams, but they probably picked up best practices and knowledge and avoided picking up career ending practices and attitudes.
There is a lot of terrible anti pattern code out there that actually works for the business and pays a lot of dev salaries. I propose that a developer that hasn't seen enough code done the 'right' way might mistake anti pattern code for a legitimate solution to a problem. The business may say that the solution works, but it's not one you want on your resume or one that you would brag about to other developers. This is also only relevant if your personal growth path includes gaining the respect of your engineering peers and not just temporarily increasing the income of whatever company you work for (Sounds bad, but in the end, the best engineering absolutely makes the most money IMO).
Unfortunately there is a lot of code and a lot of time that can pass before tech debt is revealed. And that tech debt is usually recognized exactly when it is too late. Whomever may have tried to stop tech debt or anti patterns before, could have been sidelined because of the perceived extra expense or lack of understanding of scalability ect. It is our duty as engineers to expose tech debt right away. Projects without experienced engineers are in jeopardy of hitting a brick wall at some point, actually all projects even with talented devs. Most businesses view 'some point' as plenty of time to fix it later. This makes job choices for up and coming developers a very complicated matter. It also points out the entirely different goals and mindsets between developers and businesses and how complicated it is to bridge the gap.
It is the goal of engineers to 'include' real scientific work and design consideration while it is the goal of business to 'exclude' unnecessary cost and time. Since engineers often don't know what the level of effort and time is until the end state is actually done, software development plays out like any good drama with characters like agile, scrum, and kanban playing leading roles.
One take away might be to stay away from bad code until you have seen enough good code to not be 'corrupted'. I love the saying that senior developers create simple solutions to complex problems. Like wise, junior mid level developers create complex solutions for simple and complex problems.
Another take away could be that you need to work on good AND bad code at different points in order to gain understanding. If you have done neither then go for it and be prepared to unlearn it all when you come across a better system. I think this is probably a more common trajectory for most developers.
I'm biased this year because I'm feeling like I'm climbing an extremely complicated 'secret sauce' mountain. While I will increase my ability to decipher some of the worst patterns I have ever seen, it is so 'custom' and 'one off' that I don't believe my struggle will increase my marketability or my usable skill set in my future.
In order to keep my sanity, I'm just chugging along at a steady pace and embracing every road block as par for the course. Having just reviewed my yearly goals with my boss that include digging out of this legacy hole, I'm kind of thinking it might be a sacrificial climb. I could survive the process with bad reviews and perceived slowness. This is a realistic and foreboding warning to those of you wondering what job to take.
Disclaimer: This post will live much longer than my opinions so take it with a grain of salt. Tomorrow I might love legacy code! (Doubt it).