The first problem is where should you install the modules from. The obvious answer is CPAN. Except, is it really? My team works really hard to ensure all installations go through our Artifactory. Why? So we can verify the versions of things that are installed are secure and free of malware. Malware in an OSS module?! Oh yes!

Okay, now you say "Sure, but that should be configured at the system level." Maybe. Maybe not. Maybe it's configured at the source repository level. Maybe your friendly Devops team has configured the development environments so that all development occurs within VMs and containers which mirror how production is built and there isn't an interpreter on the developer's workstation. (Yes, this is exactly what my team does for our developers.) Why? So that no-one thinks they can develop locally in a way that isn't reproducible. "It works on my machine" is a Critical-Severity failure for my team.

We haven't even started to explore the issue of dependency management. I'm not talking about Perl dependency management. Library dependencies are even harder to get right. And, no, Alien doesn't work. This is a large part of why Devops teams (like mine) really like OS packages (rpms and debs) for installing OSS modules. In fact, we have a habit of repackaging OSS modules as OS packages specifically so we can (as an example) say things like "XML::Parser depends on libexpat" and make sure everything installs properly.

This doesn't even get into the problem of Perl modules with XS. Does everyone need to have a full build-chain installed? Does that build-chain even run properly? What about those dependencies?!

Hopefully, this helps you understand exactly why programming language runtimes (like Perl, Python, Ruby, NodeJS, etc) choose not to install libraries on demand. It's not laziness - it's to allow people to be clever.