Your argument might have some sense if there was only one possible perl on a system.

But that isn't true. If it is an issue to upgrade /some/path/to/perl, then you can always use /some/other/path/to/perl. Or you call them /usr/bin/perl5.10.1, /usr/bin/perl5.11.3, /usr/bin/perl5.8.8 and have /usr/bin/perl be a link to whatever default you fancy.

Depending upon how much perl code is in production, this can be a lot of extra work. I've seen a new installation take several weeks to approve and complete.

But that's not a reason to assume that's true in general -- and I'm certainly not going to assume some kind of installment/upgrade policy when answering questions. Furthermore, organisations that have procedures in place for installing/upgrading new software usually have that for, uhm, new software. Whether that's perl, a C compiler, a CPAN module, or whatever their development department throws over the fence.