One of the key strengths of both Perl and perl, has been the way old code is still supported in the language. That is a decisive aspect as when to choose a language to invest a lot of time, and by that, money. I'll take an example that is not part of the DarkPAN and that has been, just last week, released as free software.
About a year ago, I started working in a software, and of course, I chose to write it in Perl. More than that, I have also made some interesting choices, that including the use of SOAP over XMPP to design the choreographies of the application, as well as the use of Catalyst to implement that. That led me to write some new CPAN modules. Basically I was using XML::Compile, XML::Compile::Schema and XML::Compile::SOAP as the foundation to the entire application.
As the software evolved, a new major release of the XML::Compile framework was released, and it mostly changed the API and a lot of default behaviors. This change costed me about 3 months in investigation and patches, both to my code, to XML::Compile's code and to some other modules just to have the code working again.
Imagine what happens if the defaults for the core changes? That would represent an incredibly higher number of issues to be dealt with, and we don't actually have a choice of "sticking with the old perl", because the developers usually are not the sysadmins, and having to convince a sysadmin that you need to install an old, unsupported version of a CPAN module is already bad, imagine having to convince a sysadmin to install an old, unsupported version of perl? and by that it would mean to keep an entire module tree specific for that version?
That would certainly be a reason for a manager to decide to switch over from Perl to something else, and a very good one. In fact, one of the key strengths of Perl is precisely the long backward compatibilty. And that is not only important only to the DarkPAN, but for every single piece of legacy code in the free software ecossystem as well.