Although people will tell you to always use CPAN, don't turn off your thinking cap. As a good programmer, you want to do as little new work as possible and to minimize as much risk as possible. Since CPAN is a horde of people you don't control, you can save yourself a lot of work, but you also take on a lot of risk (which is not an absolute definition).

Apply those thoughts to using CPAN too. The answers aren't going to be the same for everyone because social constraints and local policy often get in the way. The best thing to do is to have sound technical advice to inform those decisions. As always, whenever someone tells you the One True Answer before they know you're stuation, watch out!

Here's what I recommend to most people:

• If you're doing something big and there is a CPAN module that does that and everyone else uses, use it. This is stuff like DBI, DateTime, and so on. In this case, if you don't know what the answer is, just ask. If everyone says the same thing, then use that. If everyone says something different, then you have more work to do.
• If you're doing something repeatedly in a lot of code, a module is a good way to go. That doesn't mean that you need a CPAN module, but you can always implement your module using a CPAN module. This is especially handy if you decide later to change which CPAN module you want (say, use RoseDB instead of DBIx::Class).
• Consider the cost of using the CPAN modules. Most are no-brainers: the amount of work to reimplement the good ones is intractable, and the risk of recreating it with many more bugs is very high. In those cases, go with CPAN. In other cases, such as Class::Singleton, the amount of work to reimplement is trivial, and the risk is virtually zero. You don't need to use that module just because it's on CPAN.
• If you decide to use a CPAN module, what are the chances of something in CPAN breaking your application? Not only do you now depend on that module, but all the modules it depends on. David Cantrell's CPAN Dependencies chart can help you see what you are getting into. This can be a big problem, and I talk about it in my Making My Own CPAN talk. I've worked on plenty of apps that were working just fine until something in the dependecy chain broke (or changed APIs). It's a risk you need to evaluate and mitigate. This doesn't mean that you avoid CPAN, but that you come up with a strategy to freeze module versions, use PAR, or whatever.
• Some organizations are limited to core modules (for whatever reason). Does requiring an external dependency create more work than it saves? The answer isn't the same for every CPAN module. My Business::ISBNmodule might be worth it, but my Object::Iterate or File::Find::Closures modules aren't.
• I wouldn't worry so much about authors abandoning modules. The community finds good homes for the useful ones (and those are the only ones you're using, right? :)