Seems to me like there's a logical fallacy in your argument. Just because some/many modules on CPAN don't work for the version of Perl used on your production systems does not mean none of them do. Naturally, when looking for a solution to a problem you should take into consideration whether a given CPAN solution works for your production environment, that seems to me as obvious as not trying to use Win32:: modules on a *NIX system. But you should not conclude that you cannot use any CPAN modules because some of them don't fit your needs.

Also, some developers make an effort to keep their modules as backwards-compatible as possible, and if you tell a developer that you would like to use his module but can't because your version of Perl is older than his module's minimum requirements he may try to adapt the module to suit your needs (especially if your request is accompanied by a suitable patch, as suggested by mirod :-).

And I'd posit that a good system should be written with upgradeability of the underlying platform kept in mind, and a cardinal rule for that is "don't use undocumented or deprecated features". I am perfectly aware that this is often not possible without huge effort (particularly since the time-machine which lets you preview future features of Perl seems broken again), but it should be one goal when writing such a system. Sticking to old and deprecated platforms can create massive problems at a moment's notice (like when a serious security flaw is suddenly found and no fix is backported), and while it's sometimes unavoidable it should not be a goal IMO, or considered "the way things are done".