There are many repositories, and even more reasons.

Consider CPAN, for example. That repository maintains a copy of just about every version of Perl, partially for historical value, but also so that authors of modules can access older Perl versions to verify compatibility of new code with old Perls.

perlbrew can install latest releases of all major versions from 5.20.2 back to 5.003_007. Again, this is useful to people trying to establish compatibility with older Perls, or trying to develop code that targets a production environment that still uses an older version.

Vendor repositories (CentOS, Redhat, Debian, etc.) may prefer stability over latest, at least for their production branches. And that being the case, they may prefer the devil they know over the devil they don't. Just as people are discouraged from upgrading system Perl because they may break system code that targets a given version, vendors are also reluctant to go through the process of regression testing all their established system code against a newer Perl version, and reluctant to force changes on their end users when those changes could have unforeseen consequences.

OS vendors have to balance the benefits of keeping their version of Perl up-to-date (bug fixes, security patches, etc), with the time costs and stability costs; the time it takes to build new rpm's, deb's, or whatever, the time it takes to test all system code that uses Perl, and the time it takes to support users who uncover code compatibility problems that the vendor could hardly anticipate. Time is a scarce resource.

And businesses that build their systems on Perl are also going to be fairly slow to upgrade their production-environment Perl for many of the same reasons. The possibility of something breaking with an upgrade is a strong deterrent. Especially if the production code base's regression test suite isn't comprehensive (as is often the case).

All this only scratches the surface. Everyone has their own reasons, even if the reason is only "don't fix what's currently working." Most Perl developers I know enjoy installing and using newer Perls in their own sandboxes; tinkering with new features, fantasizing over how their code would look saner if they could just use some new feature, and so on. But at the same time, they understand the reality that it's a lot easier to install a new Perl in a tinkering environment than in a dev/production environment. The Perl version being used in production is really a form of technical debt, after all.