So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):

I strongly disagree with almost all of them, because they all start from the same point. Why?

short answer

If it ain't broke, don't fix it. You should probably NOT mix your custom libraries with the system libraries, but that is a whole different point. Perl has PERL5LIB, lib, FindBin and more ways to include paths unknown to the system within perl's search path.

long answer

All of the arguments in favour of installing your own perl don't hold if the system's perl isn't suspicious in one or another way. I rarely found a seriously broken perl core installation - well yes, RedHat is doing such a terrible job here sometimes that one might suspect they want to discourage the use of perl all together. But in general, the perl core installation is - just perl core fine-tuned to the capabilities and requirements of the system you are using. Why would you be smarter configuring a suitable perl than those which oversee the whole system?

If the perl core of your system isn't too much outdated for your needs, why not just use it, along with the pre-compiled packages provided by your vendor? Your system probably provides a toolchain to build perl packages, and with minor tweaks, you can install any additional or newer version of needed modules into a custom path, even application-wise, and prepend that location to your @INC. That way you are only responsible for those packages which you absolutely need with newer features or custom bug fixes.

Some reasons why your system's perl might be better than a custom built perl:

• the systems's perl is always up to date with system libraries
• your vendor might provide you with new packages containing securtity/bug fixes for problems you are not aware of
• the vendor's approach is almost always conservative - they are not interested in breaking perl (but see RedHat) as part of the system
• using a reasonable well built perl including packages built with that perl and it's toolchain saves you work and reduces your technical debt
• chances are higher that problems within your system's perl are known out there, and that there is a fix - you might get better support and hotfix packages

Of course, if building your essential modules turns out to be a nightmare with your vendor's perl - then that perl build is broken. Roll your own, complain, and if possible, provide upstream patches.

perl5porters, module authors and the perl community at large as well as vendor software maintainers are generally doing an awfully good job at providing a perl out of the box which just works, and deficiencies of older UNIXes like AIX or Solaris, b0rken stuff like RedHat's perl v5.8 or braindead update procedures like on MacOS are no reason to degrade perl's fame of being way better in backward compatibility, write once - run everywhere and robustness than Java, Python or PHP.

Generally advocating always roll your own perl is a disservice to perl users and programmers.

tl;dr

If you know what you are doing, and why - build your own perl. But always disregard the system's perl and build your own MUST NOT become another of those recommended Perl Best Practices.
Summary:

In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.

If the perl shipped with your OS is broken, get another OS. Why should the OS be any less broken than perl on that OS?