in reply to Top 11 (GOOD) reasons not to use someone else's Modules
Most of the points you list deal with the complexity of integrating and managing 3rd party software (specifically CPAN modules). The rest of it speaks to a preference for just doing things yourself. You're not the first to feel this way about either of those two subjects. I'd submit that your list of arguments is based in your distaste for the former and enjoyment of the latter.
You make a number of valid points about the pain of dealing with CPAN modules. I've yet to meet someone who enjoys wading through someone else's code to figure out how an undocumented edge case is handled. Nobody likes figuring out a deployment/upgrade strategy for a large set of installed modules. People might get physically ill after participating in a long email thread with their company's legal department (ha). None of this stuff is fun, while writing your own code clearly is. You're not on PerlMonks if you don't derive deep satisfaction from crafting a chunk of software on your own. Everyone loves hacking.
The problem is, dealing with the distasteful stuff like managing CPAN modules is many times more efficient than writing everything yourself. You are dead, dead wrong on point 11 - you are definitely not paid to "write code" (at least I hope not). Your job is to deliver reliable software efficiently (in time, cost). The unfortunate truth is that one has to deal with the unenjoyable parts of $work to find this efficiency, at the expense of doing the fun things like hacking away at code and learning new things.
One of Perl's great strengths is the breadth and quality of user-contributed software (on CPAN). Like anything else large, it takes time to master its complexities (some of which you listed), things like managing dependencies, licensing issues, gauging a module's quality, etc. But if you do, you'll be able to deliver a better product, and your employer (me, a US taxpayer!) will thank you.