Yet another "this is the way to do it, and anything else sucks" post. Let me pick at some of your arguments:

It may seem that way now, but what if you haven't considered all of the possible cases your code will have to handle?

What if I have? What if *I* have, but the author of the module didn't? How would I know the author did? I might audit the modules code, but if the task is simple (but important), writing it yourself may be more efficient.

What about if (when) your requirements change?

Well, so what? In point 4, you warn against premature optimization. Coding against any possible requirement change in the future is premature optimization. The scrum methodology actually forbids you to do so: it's just enough, just in time. Now, I'm not a full scrum adept, but one of the signs of a good programmer is that he can make the right trade-offs. Which does include knowing when to spend resources now against possible future requirement changes, and when not. Note that any resource spend coding for a possible requirement change that will not happen is a 100% loss. Certain things just are too unlikely to change before your code is discarded.

Module authors have usually had time to consider the edge cases.

Really? How do you know? Or more important, how do I know? If there's a module on CPAN doing X, what tells me the author has spend more time considering edge cases I will do? Remember, the existence of code on CPAN neither implies a stamp of quality on the code, nor on the author. I've a pretty good idea of the quality of my code, and of the quality of the code my co-workers write. I've some ideas about the quality of the code of a small subset of the CPAN authors. Of the majority of them, I've no idea how good they are, and whether the module I may use reflects that.

Many modules are implemented using XS bindings to compiled C. Those are typically going to be faster than any implementation you can come up with in pure Perl.

There's something magical that happens with authors when writing code for CPAN that doesn't happen when people write code that may use a CPAN module? CPAN authors will use XS everytime it gives a significant speedup, and others never will? Come on. People write XS code. Some of it will stay in house. Some of it appear on CPAN. Some people never write XS code, even if it would make their code faster. And guess what? Some of that code ends up on CPAN as well.

Fine, so install them locally!

Oh goodie. So, you'll end up with code that passes 100% of the tests, but doesn't even compile when rolled out into production. Great advice! Not. I've worked in several companies where there's a procedure for installing third party software. Third party software is for instance only installed from RPMs. Which means that if I want module X to be installed, I have 1) find or create an RPM containing that module. 2) Do the same for every dependency. Recurse. 3) Create a ticket for operations to install the RPMs on development and production. 4) Wait for it to be installed. Now, at $WORK operations is pretty quick and there's seldomly an objection against installing CPAN modules. But if I work on a problem in the evening, and I've the choice between writing something simple myself and putting it live right the same night, or hunt down an RPM, create a ticket and wait till the next day, it's easier for me to write it myself (less work), and better for the company (bug fixed/feature implemented faster).

And here's another reason. Some time ago, I needed some piece of functionality. There's a CPAN module whose most recent versions having this functionality. We have this module installed at $WORK. Except, not the most recent version. With the most recent versions, our code will break. Considering that it's not an easy task to have two versions of the same module installed, and have some code use one version, and other code use the other (it's not impossible, but it doesn't work that way out of the box), I opted for writing the feature myself.

Perl code is wonderfully portable, even with module dependencies!

Often it is, but not always. Module authors usually don't have a wide range of platforms or OSses to test against. (Nor do I think there's any obligation for a CPAN author to test it against a wide range of platforms). Sometimes, code just doesn't work correctly in a different environment.