I used to think this way. After living without CPAN for 3 years using different languages, I appreciate the lack of dependency additions my projects get.
The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case.
Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful.
At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.
I blame your sysadmin for not making it easy. Even so, you probably don't rely on CPAN all that much if you lose more time to dependency problems than you save by re-using other people's code. That's not my experience at all. I save days and sometimes weeks at a time.
If you're running through 100K lines of code to test a DBI upgrade you're clearly not testing properly. Not that most CPAN modules break compatibility. It's very rare that something like a DBI upgrade will break anything. All the good module authors are very careful.
The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case.
Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful.
At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.