I find your reasoning a little suspect:

Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated...

In fact, that isn't typically true. All that's required to move from one version of Perl to another would be regression testing, which is typically automated, followed by a brief UAT period. If there are problems, then you can get into software development cycles, but such problems don't often occur (and are typically failry minor when they do).

It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1.

There are not all that many modules which require 5.8.x. Most of the time, when I see people asking about solutions that use core modules only, the CPAN modules that would solve their problem work just fine with quite old versions of Perl. A more reasonable request would be "I have perl 5.6.1 and that can't be helped: so I can't use any modules that depend on newer versions." Unfortunately, that's not what we see, most of the time.

There are only two common reasons for a corporate requirement of "no CPAN modules": code vetting and licensing.

In many organizations, any production code must be vetted by Quality Assurance (QA) and Security Review (SR) teams. Sometimes both functions are performed by QA. In any case, the core Perl distribution tends to have been vetted by these teams as safe for production use. All code written in-house will follow corporate coding standards and is therefore a bit easier for QA/SR to clear for production. CPAN modules (a)are a bit harder to review and (b)might have to be handled outside the project, slowing production. It would be easy enough for a corporation to establish a better review process for CPAN modules, but often they apply the same rules that were designed for external modules in other languages (which often do not have source code). The coder on the floor doesn't usually have enough pull to get the policy adjusted.

As for licensing, many CPAN modules are GPL or a similar "viral" license, and that makes legal types nervous. We all know that using modified GPL software internally creates no burden, but corporations tend to be risk-averse and would simply rather avoid the potential for licensing concerns. Thus, policies grow that forbid external modules without a long and painful code- and license-review process.