For me, an example of an "enterprise level requirement" is a need for an accepted series of design patterns and underlying technologies for supporting software transactions accross multiple machine boundries with completely different transaction methodologies.

For example having an atomic software transaction which needs to update a series of databases (perhaps Oracle and MS-SQL, as an example) as well as fire off some CICS transactions and to be incredibly nasty, an update to an LDAP system. This is where going with an IBM J2EE stack makes sense, and this is where they "shine" as an enterprise application framework. From monitoring the livelyhood of your system with a Tivoli installtion, to perhaps using MQ for asynchronous message beans (oh, it seems that the mainframes are busy doing reports for 1/2 of the day, and we need an infrastructure that provides transparent asynchronous transaction execution) to being able to leverage it with a bunch of webbie programmers by giving them a custom tag environment to work within from within JSPs, and knowing that this environment is multi server failover "guaranteed" due to Websphere server clustering.

That's the sort of thing that's "enterprise" to me. 99% of the work in the software world is sure as hell *not* enterprise :) (At least in my humble experience...) Oh, and to finish off, yes, I do know that all of this is doable with Perl... hell, I'm sure it's doable with emacs lisp :) It's just that Perl doesn't have a quijillion dollar corporation betting their reputation on continuing to iterate through these tools and make them better and more suited to similar "enterprise" needs.