I'd like to strongly second this request.
Now, I've done a bit of counting and found ca. 38 'perl_*.tcz' extensions in the 3.x repository: 23 submitted by user AlabamaPaul, 5 by BashlykovNikolay (which I could not find any more in the members list), 4 each by juanito and Arslan S., and 2 by bmarkus.
Unlike the situation with Python there are only a few extensions in the 3.x repository that depend on a Perl module and are themselves not a Perl module extension (e.g. 'autoconf.tcz', 'frozen-bubble.tcz', 'icon-naming-utils.tcz', 'intltool.tcz', 'pcb.tcz' and 'system-tools-backends.tcz'). Their dependencies are 'perl_xml_parser.tcz', 'perl_xml_simple.tcz', 'perl_gettext.tcz', and 'perl_Net_DBus.tcz'.
In my own professional experience (gained predominantly a few years ago) a Perl script created for example during then 5.6 phase would typically not need any change to run on a 5.8 or 5.10 system. I like to think that much more effort has been put into staying backward compatible for the Perl5 version progression. Therefore I'd be highly surprised if any problems would arise from the ca. 37 extensions that require the 'perl5.tcz' extension (and are themselves not a Perl module).
Considering also that only very few extension contributors would need to coordinate any change I'd like to think that a "big bang" approach (i.e. update 'perl5.tcz' to v5.14.2 and approach the Perl module extensions maybe by prioritising those mentioned above) is quite feasible. Clearly I'm not suggesting to go down a renaming and dual version exercise (along the lines of Python 2.6 vs. 2.7). I think the lower "popularity" that Perl enjoys nowadays and the more contained number of modules should make it easier to take the plunge now still at the very beginning of the 4.x phase. I don't think that the IMHO remote risk of noticeable breakage does warrant a postponement to the TC 5.x phase.