I think this is a huge problem, but as tempting as it is to blame the situation on "the youths" and their lack of respect for their elders or legacy code, a huge part of this is the fault of our industry and the businesses themselves.
The first thing is that I think people who don't want to work on legacy systems are making a pretty rational system based on the state of the industry these days. We recruit people heavily based on whatever they've done most recently, and for a lot of people even a short stint on a legacy system can be a career ending dead-end. In very competitive markets it might not be quite as bad, but for a large swath of the market (for instance in the Midwestern US, where I'm at), a single job with a legacy technology can make you nigh unemployable doing anything else. The problem is compounded by the fact that a lot of "recent legacy" technologies simply don't pay as well as either very legacy technologies (where you might be expected to have 20+ years of experience) or hotter new technologies.
Next, I think that we need to consider that, frankly, a lot of legacy code and technology sucks. New tools might have the same, or more, underlying fundamental issues, but in a lot of cases newer technology has a thicker layer of ergonomics on top, and the technologies themselves haven't ripened enough for the code smells to be noticeable, so from a day-to-day job enjoyment standpoint that somewhat lower paying job that is going to pidgeon hole you into the same boring BigCo work for the rest of your career is also going to come with a side dish of increased frustration. There's also a particular place in hell for certain types of legacy systems that really embraced the fads of their time- e.g. inheritance astronaut OOP hellscape Java applications from the late 90's, or rube-goldbergian metaprogramming funhouse ruby projects from the 2010's (I suspect the particular flavor of grotesque FP-look-alike cargo cult nonsense non-FP languages are trying to shoehorn onto poorly typed highly mutable environments is the fad that will give next decade's legacy system maintainers night sweats, but it's always hard to tell when you're in the middle of it).
Finally, and I think this is the biggest factor of all, a lot of companies with big legacy systems are digging their own graves because it's not just that they have legacy systems that need to be maintained, but they are so traumatized by the difficulty of keeping those systems up and running that they have calcified beyond any ability to experiment and try anything better, so it's not just that there are legacy systems to be maintained, all new work ends up getting shoehorned into the same legacy languages, legacy frameworks, and legacy business processes, because the fact that they never managed to migrate off their 1970's COBOL applications means that everything written today has to be designed to last 40 years using 20 year old technology. If engineers who were expected to maintain the legacy systems had some leeway to also experiment with newer technologies, and to modernize some parts of the system (with the acknowledgement that not all experiments would be a success), then it might be a lot easier to keep those engineers around.
The first thing is that I think people who don't want to work on legacy systems are making a pretty rational system based on the state of the industry these days. We recruit people heavily based on whatever they've done most recently, and for a lot of people even a short stint on a legacy system can be a career ending dead-end. In very competitive markets it might not be quite as bad, but for a large swath of the market (for instance in the Midwestern US, where I'm at), a single job with a legacy technology can make you nigh unemployable doing anything else. The problem is compounded by the fact that a lot of "recent legacy" technologies simply don't pay as well as either very legacy technologies (where you might be expected to have 20+ years of experience) or hotter new technologies.
Next, I think that we need to consider that, frankly, a lot of legacy code and technology sucks. New tools might have the same, or more, underlying fundamental issues, but in a lot of cases newer technology has a thicker layer of ergonomics on top, and the technologies themselves haven't ripened enough for the code smells to be noticeable, so from a day-to-day job enjoyment standpoint that somewhat lower paying job that is going to pidgeon hole you into the same boring BigCo work for the rest of your career is also going to come with a side dish of increased frustration. There's also a particular place in hell for certain types of legacy systems that really embraced the fads of their time- e.g. inheritance astronaut OOP hellscape Java applications from the late 90's, or rube-goldbergian metaprogramming funhouse ruby projects from the 2010's (I suspect the particular flavor of grotesque FP-look-alike cargo cult nonsense non-FP languages are trying to shoehorn onto poorly typed highly mutable environments is the fad that will give next decade's legacy system maintainers night sweats, but it's always hard to tell when you're in the middle of it).
Finally, and I think this is the biggest factor of all, a lot of companies with big legacy systems are digging their own graves because it's not just that they have legacy systems that need to be maintained, but they are so traumatized by the difficulty of keeping those systems up and running that they have calcified beyond any ability to experiment and try anything better, so it's not just that there are legacy systems to be maintained, all new work ends up getting shoehorned into the same legacy languages, legacy frameworks, and legacy business processes, because the fact that they never managed to migrate off their 1970's COBOL applications means that everything written today has to be designed to last 40 years using 20 year old technology. If engineers who were expected to maintain the legacy systems had some leeway to also experiment with newer technologies, and to modernize some parts of the system (with the acknowledgement that not all experiments would be a success), then it might be a lot easier to keep those engineers around.