Quite frankly, if these are (even semi-) experienced programmers, I'd throw most of what you've listed away. They are either

• too simple--like Data::Dumper.

  They won't appreciate how useful it is, until they've tried dumping Perl data structures manually, as they currently do in whatever languages they are used to, but will tend to think: "This is what Perler's get excited by..."

  Far better to just use it as a part of demonstrating something else, without actually making any fuss about it. They'll then know it's there, and when they need it, they'll know what to look for.

• Too complex--like Moose, POE, Catalyst, Jifty,.

  No brief overview of any of these is going to do any one of them justice. And API tours are about the most boring way to spend time that you'd rather spend doing something else.

  And for goodness sake leave B::Deparse et al. completely unmentioned unless you want the "conceptual model wars" to be their abiding first Perl experience.

If you want to enthuse programmers for a new language, show them what it can do for them. Something relevant to their experience and/or imminent tasks.

That's why that RoR video was so effective. It showed people who've been struggling for months and years with PHP/JavaBeans/CGI.pm&Template::Toolkit how much of their current and previous efforts had been expended repeatedly servicing the requirements of their tools and environments rather than their specific applications. Repeatedly reproducing stuff that their tools should be doing for them. It's that "let me do the stuff I need to do and let the tool take care of the rest" that grabs so many Ruby neophytes by the scruff of the neck and turns them into devotees.

Find something that matches their immediate requirements. Start with a 'blank canvas' that includes all the good stuff--strict, warnings, Data::Dumper; whatever else is relevant--and take them through the steps of turning that into something (simple!) that works.

Install a relevant module "in front of their very eyes", and then just use it. Look something up with perldoc, or the on-line html, as a part of the process, without getting into details about it. Write your tests and then use them to test your code and locate a 'bug'.

And leave plenty of time for questions. Because if you do it right, there'll be plenty. Indeed, you can use the number of hands that go up when you first ask the "Any questions" question as a strong indicator of your success.