One of my first summer jobs as a programmer was largely based around scraping green-screens and PRN files. Back then I probably wouldn't have minded getting my hands dirty in COBOL (that is if they had trusted me enough as a student to let me into that code), but I'm not sure if I would feel the same way about the same prospect today.
I don't think the issue is really with mainframes per se. It's our industry's (often justified) obsession with the new and shiny.
Look at C. C is still obviously a critically important language. Almost all embedded code and most operating systems are written in C. It's not going anywhere anytime soon. And yet it's getting harder to find C programmers. A quick gander at the Stack Overflow tag page places it at 1/6 the size of [c#] and 1/4 the size of [java]. Does anyone remember when C was essentially the dominant language, arguably the only game in town?
Programmers love powerful tools. Maybe that's because (SPECULATION ALERT) most programmers are guys. You give a Java or .NET programmer the task of, say, copying a file, and many if not most will still choose to write it in Java or C# instead of writing a DOS batch file or *nix shell script that would be 50 times quicker to write and deploy. Why use a rod and reel to catch a fish when you've got a gigantic retractable net that can catch 500 fish?
Yes, COBOL and PL/I are old, but so is Pascal, and it's still alive and kicking in the form of Delphi. The aversion to the former probably stems from the fact that those languages are unwieldy compared to modern tools. Object-orientation is still a relatively new concept in the COBOL world (emphasis on relatively), but in the C# world, LINQ and generics and AJAX stopped being revolutionary years ago. Asking a developer accustomed to those tools to start programming on mainframes is like asking a rock musician to start playing on a banjo.
Of course there's also the problem of the self-perpetuating stereotype. As long as younger programmers believe that there's nothing for them in mainframes (whether or not it is true), then any young programmers who do choose to go into it will end up spending most of their days around people much older. IT isn't much of a socially-appealing profession to begin with, but the added disincentive of a generation gap tends to bring it below a lot of people's pain thresholds. No offense meant - I personally have spent most of my life working with people a good deal older, but not everybody has that background or that capability.
Finally, most programmers don't enjoy maintenance work, and almost all mainframe work is maintenance. There isn't a lot of new software being written in PL/I. Any job that is defined entirely or largely around maintenance code automatically starts off with a negative score.
There are positives to working on legacy code ("legacy" encompassing mainframes and many other things), which you'll probably need to play up if you're trying to attract a younger crowd:
The systems are, as you say, critical infrastructure. Younger developers, at least in the business world (not Google/Microsoft), often don't get a chance to make any real impact. It's disheartening to work on a system that you know is just going to be abandoned or superseded after a few months or years. Mainframe apps that have already been running for 50 years are probably going to run for a lot more because it makes no sense for the companies to rebuild them, so the work you do in them is actually important to a lot of people.
If you are one of those few companies that actually does have an inclination to "upgrade", then a lot of programmers, both young and old, will be attracted by that opportunity, because then there are twin opportunities to work on mission-critical code and to flex some of those C#/Java muscles. Obviously no sane company would just scrap the mainframe and rebuild from scratch, but I've seen systems which (for example) have a COBOL core that integrates with Java components.
Finally, there's the indispensability - at least, as we outsiders perceive it. When all your code is in .NET then there's always the risk that the owners will trade you in for a fresh-out-of-college graduate or worse, an offshore team, in a misguided attempt to cut costs. I don't think that happens very often in the mainframe world, especially if what you say is true and supply seems to be dwindling. Of course, this point is moot if you don't pay well enough; salaries need to be adjusted to reflect that dwindling supply, otherwise people won't "sell."
I'm sure there are a lot of younger developers out there who wouldn't refuse a reasonably generous offer from a company that appeared to be going out of its way to make the work environment appealing to younger employees. But if you want to reach them then you'd be wise to play on your strengths, and you might even have to start doing some marketing; we tend to view mainframes as a different and very foreign world, and I'm pretty sure I didn't see you guys at the campus job fair 10 years ago working to change that perception.
To boil it down to a single sentence: Nothing makes mainframes unattractive, it's just that nothing makes them attractive either, and that puts them at a serious disadvantage when compared to the bleeding edge which offers us huge productivity boosts and free soft drinks.
