It may be technically solid but still a bad bet. Flex/Air are essentially deadend platforms as Adobe jumps on the HTML5 bandwagon with its toolset. If he puts his effort into developing his Flex/Air skills, he's targeting a shrinking install base and future market for jobs. If he puts it into HTML/JS/CSS instead, he's targeting a large and growing install base, for mobile, browser and Win8 desktop apps.
I think a platform that makes developers struggle with implementation details and browser quirks is a dead end, no matter what Adobe does.
In my experience, there's a low signal to noise ratio when learning HTML/JS/CSS. A lot of it is learning hacks, as opposed to getting a general sense of how computers work. Flash/AIR are very good in this regard. If Flash disappears tomorrow, I don't think his skills would go to waste.
See, statements like this really get under my skin, because they're wrong in so many overlapping and crisscrossing ways, it's hard to know where to begin in responding to them.
First, "Flex/AIR", as you say, doesn't make sense -- there is no such thing as "Flex/AIR". Flex is one thing (a bunch of open-source code), AIR is another (a bunch of runtimes). You can't just throw a slash between them and call them the same thing, because they aren't, and indeed Adobe's roadmaps for both are completely separate and in this case divergent. To those who aren't familiar with the Adobe stack, it sounds like you know what you're talking about, but to those who do, you just sound like yet another uninformed FUD-spreader.
As an ActionScript framework, Flex is only "dead-end" insofar as the Flash player itself is dead-end, which at near-total penetration on the desktop puts it about as far from extinction as anything could be. Flex per se, as a Flash-targeted framework, is only dead-end if someone builds something better to replace it, which also doesn't appear to be happening anytime soon, as those of us who do choose to use Flex generally happen to like working with and contributing to it. And last I checked, open sourcing a project was anything but sentencing it to death by definition.
Despite abandoning Flash for mobile browsers, Adobe is actually redoubling its efforts around Flash for the desktop and the various AIR runtimes, which are, of course, extensions of the Flash player.
And not for nothing, but polygeek is already a Flash developer -- he's not "putting his effort" into learning these skills; he already knows them. He's merely complaining about the prospect of having to learn another way of doing something he already knows how to do and enjoys.
For my part, I'm equally experienced in both the Flash stack and in Web scripting, and I dig both; I love my Flex and love my jQuery, love JavaScript and the prospects (if only partially realized) of HTML5, and I've been around long enough to know that both have their applications and there are plenty of places where they don't even remotely overlap -- despite how often comments like this seem to suggest their interchangeability.
So yes -- if you're writing Web apps that'll have to run in mobile browsers, then obviously, you shouldn't use Flash. But Flash and AIR are not going anywhere, and Flex is there for your use if you like. That's a little closer to the truth than "Flex/AIR are dead-end platforms."
FWIW, I'm not responding at this length just because I think you're wrong and feel some need to correct you. As a consultant, fairly recently, I has a good-size project go less than spectacularly because some underinformed product manager decided to impose a "no stinking Flash!" policy on an application intended to run solely on desktops simply because she'd gotten the sense somewhere, God knows where, that HTML5 was trendy, and Flash was passe (and despite my having built several successful Flash projects for them previously). The problem, as I was forced to point out repeatedly as we went through the project, was that many of the functional and design requirements they'd set for it were tailor-made for Flash and Flex and trivial for them, but because they'd excluded it as a technology choice, the equivalent functionality without Flash would require considerably more time, be less uniformly compatible, and in some cases just couldn't even be done. By enforcing no Flash, they ended up with an inferior product, and all because of an arbitrary and unnecessary technical constraint. (And on the next project, they opened the door to Flash again.)