I am not a "real" sysadmin in the sense that I neither get paid nor do maintain a system that is used by more than a handful users. That said, my approach for maintaining a Perl installation would be to add a perl user group and install the "company Perl" under /opt/perl. All users in the perl user group can install or upgrade modules from CPAN with that custom Perl.

Important reasons for me to keep a separate Perl installation are that the system Perl belongs to the system. Important decisions, like whether to build Perl with or without threads and/or to build mod_perl should not rely on the decisions for the system Perl, because the factors going into that decision for the "general use stock Perl" might well differ from the factors influencing my decision. Also, specific language features or the package repository used might influence my decision here.

In general, I've come to the conclusion that for maximum stability, I want a separate Perl installation for every application, if not a separate virtual machine for every application. This of course makes maintaining the (security) upgrades a hassle. An interesting midpoint might be to use something like Carton to package up a specific set of modules and still use a common Perl binary.

Using the stock Perl is always problematic in the long run for me, because it is highly likely that I want a module that is not (yet) packaged by the distribution maintainers. I could install the module into a local directory, but that means that I will still encounter breakage if the distributors decide to upgrade the stock Perl to a new version. Apple security updates to Perl for example tend to break manual (XS) module installations because they are not always binary compatible.