So, there's a single distinctly good reason to use modules that have already been written: they're already written, which means you don't have to write them. That saves time off your schedule from blank file to completed product. However, in the Perl world at least, it feels that there's reason to assume this may not always be the best course of action.
I'm actively considering writing (and somewhat working on) a database for library along the lines of Sequel. I've looked at RoseDB and DBIx and neither really seemed to match the It Just Works simplicity of Sequel for basic ad-hoc querying/runtime object construction, nor the flexibility and power of building more complex queries without advanced SQL knowledge. Your mileage will vary on whether you feel building complex queries entirely in Perl should be necessary, some will say you should just write raw SQL if it's that necessary, and that's a valid point but not one I'll be discussing.
Database libraries are, however, a good point for discussion on reinventing wheels, as they've been largely done to death. As I mentioned, there are at least two very well-documented and supported ORMs for Perl already. There are a myriad of supporting libraries that work with, for, and around them. Some of these libraries are actually not so inherently tied to the original ORMs that they cannot be repurposed to serve another master; in this case, me.
But do I really want to use them?
The library I'll use as my prime example is DateTime::Format::Pg. It's a library which supports converting a time-based field value in the PostgreSQL database into a full Perl object with methods and joy and rainbows. It does all this magic at the low low cost of installing a CPAN module (which can be managed by listing a dependency in the CPAN config), and trusting that the author will maintain that code sufficiently for future releases.
For supporting evidence, I'll point to Time::Format. This module presumably works pretty well, until you hit version 5.14. There, a slight syntax change has resulted in the tests failing. CPAN is very adamant that you always run tests, and while this is a time-sinking pain in the ass in most cases, it actually showed a problem here which is probably not recoverable until the module is patched. Here's the issue: author rights are a very tricky thing on CPAN. Once an author has published a module to the CPAN namespace, unless the author specific relinquishes it to another author for maintenance/whatever, it takes a minor act of God to give the rights over to anyone else.
This puts anyone who has built a library on a module by an absentee author where the module breaks because of a perl upgrade in a sticky situation. They can patch the module locally, upload a changed version in a different namespace to CPAN, and update their dependencies to point there, but this just adds more complexity to a perl upgrade process. Granted, perl upgrades should only happen around once per year, but more pain is still more pain.
In addition, this also has several side effects. It creates additional modules with the same functionality on CPAN (something this entire process was designed to avoid), requires at least partial wheel reinvention (another thing that was heretofore avoided), sometimes places the author under unfavorable licensing conditions depending on the original source module's licensing (see: flamewars on GPL vs. BSD/MIT style licenses), and, if the author's modifications are accepted as the new de facto standard version of the module, it places that author in the position of maintaining the library and the supporting module.
All this to avoid reinventing a wheel that ultimately fell off the axle.
While I can certainly feel that reinventing the wheel is a world of hurt that nobody really needs, I am very, very wary of relying too much on the rest of the world to be maintainers in perpetuity. After all, these modules were offered gratis to the world, and people can either a) stop caring, b) stop coding, or c) die, all mostly at their prerogative. Relying too much on someone's ever-continuing good will is a fool's game. So is trying to build a system from the ground up when more than half the pieces are lying around. So what's an enterprising author to do?
First, it's a healthy thing to evaluate how much your module really needs to do, and where it lies inside the greater framework of an application. If your module is a quick-and-dirty ten-minute wrapper around three separate modules, which just simplifies/streamlines the API, or otherwise provides some glue, then relying on those modules is fine, cause it's assumed the end user already intended to use them. If, however, you're writing an entire framework, it's worth trying to limit your outside dependencies.
You can't, and shouldn't necessarily, eliminate all outside dependencies. For instance, I'm writing a database library, and it would be stupid to try to rewrite DBI from the ground up. The same goes for whatever DBD::* classes I need to use. My code will simply wrap them all in a single API. However, for things like Date/Time processing, it feels like that's something that not everyone who uses my library will need (in addition, DateTime::Format::Pg implies PostgreSQL databases only, which I don't want to be restricted to).
Here's where I'm going to take another page from Sequel's playbook. There's a gem you can install, but don't need to install, when using sequel with the PostgreSQL adapter. It's called pg_sequel, and while it makes your queries run faster using a C backend, it's not strictly necessary. I think dealing with time formatting, and whatever other modules may already exist, in a similar way, is the right way to go.
That is to say, we can use a wheel that is ugly/slow/stupid compared to DateTime::Format::Pg, but if we detect its presence on a system, we can use it and suddenly we have huge silver rims and spinners. In this way, I'm not relying on something which may fall out of date with current versions of Perl, which keeps my library's dependencies for basic function light, but also allows it to grow in functionality without much user intervention.
But that could just be me being crazy.