At the end of last year after a lot of effort we went live with a new quality initiative at work. Most of it was done in SAP but the custom interfaces to test equipment and instruments was done with Perl - it was used as the glue to hold it all together.
I sent an email to Proud To Use Perl. After an initially positive reply, in the new year I received a more depressed email so instead I posted a brief summary of the story on Perl Is Alive here: Perl Helps Medical Company. It's not great but it's a start.
<rant>While I understand the mantra, I'm constantly fighting a mantra of use "SAP Standard", or more recently use "SAP XI/PI and Java". If you have bought SAP and are using it's PI mapping tool then it's best to use it, but it's just not an appropriate tool to do everything and it's nice to have a success story that isn't some monstrous Java framework that takes an eight core AIX box just to run and a team of developers to write and maintain - even if it is "standard".
Companies are scared of bespoke solutions because they fear that they may be trapped with a unique solution that they cannot maintain. They run to Microsoft or in our case SAP/Java without any real understanding of the shoddy quality of the solution they are getting. In the end it's more important to have a "standard" solution no matter how inferior it is. Perl isn't considered standard, so it always comes out worst.
On Monday an Axon consultant was horrified that I'd consider writing a Perl daemon to receive instructions by SOAP, SAP RFC or HTTP in Perl in a few hours. Creating a process like that requires weeks of development in Java, you can't possibly say writing something like that is trivial... Okay I may have overplayed the advantage that CPAN gives to Perl, but some things - in my case, most things - are a lot easier in Perl than Java!
</rant>