|The stupid question is the question not asked|
It's not the usability of Perl that is in as much doubt, as it is Perl's maintenance, administration, and re-usability that keeps it out of reach for developers in mainframe centric organizations.
I have spent this last year writing white papers and giving lectures on Open Source and Perl in particular for my 'mainframe centric' company. We now have passed proof of concept for linux on the mainframe and have two internal clients (out of hundreds) that are pushing foward with Perl dependent projects.
However, Perl is still stuck in the legal offices. This company has been able to collect money for every CPU cycle and re-use of every script from every project. Code that is neither owned by the corporation or liable by another company is kept out of production. Open Source is in total opposition to decades old philosophies and practices.
I'd also like to point out that behind most of the sites you list as proof, are corporations that are being the clearing house for all the credit card transactions (and credit bureau checks) they process. You WANT a conservative organization managing such processes. Furthermore, none of the sites you list above, manage projects that span the number of various simultaneous projects, protocols, security and support issues that mainframe centric organizations tackle daily as a matter of course. (I'm not even going to get into the diametrically oposed mindset/culture of Open Source developers and Mainframe developers).
Until Perl can prove it's feasability in managing reusable components accross diverse achitectures and projects as Java (i.e., Application Servers), it will remain just limited to 'duct-tape' operations in the Enterprise.
This is not a goal that is too far off the horizon. Another part of my job is to evaluate Java Application Servers, and I can tell you they are all seriously overpriced, overbloated, over acronymed monstrostities that are little more than J2EE enabled webservers with high pressure marketing departments working harder than their technical departments are to support or develop them.
coreolyn -- Duct tape devotee and corporate Open Source choir boy.