Sawyer X suggested that CPAN authors write modules due to Perl's sysadmin heritage, and Steven Haryanto responded that CPAN authors write modules because modularity is a huge design goal.
I agree in part and disagree in part. Perl's sysadmin heritage does influence design decisions, and modularity is an important feature of modern Perl development... but there's an easier, simpler, more fundamental reason why the largest repository of Perl code in the known world is primarily modules and not applications.
CPAN's design encourages the development and use of reusable modules.
By categorizing code by modules, by maintaining dependency lists between modules, by resolving dependencies automatically on successful installation, CPAN has ensured that the primary unit of code sharing in the Perl community is the module. This is not solely a fundamental design feature of CPAN itself—it's the result of a design principle of Perl 5.
The active language design principle is to allow people to make their own lexical changes that do not interfere with other lexical changes from other people, and to use those changes to improve the language in terms of its intrinsic features or its ability to work with the external world. (Many of my criticisms of and suggestions for Perl and the CPAN occur in places where this lexical extension isn't as lexical or as extensible as it could be.)
In other words, the Perl 5 module system had a goal of enabling things like Moose as much as it allowed DBI. The points of collaboration between programmers, especially for the types of software for which Perl 5 is most suitable, are reusable components. You want to read data from an LDAP server. You want to improve exception handling. You want to produce pretty charts.
It's not that Perl programmers don't write useful, usable applications all the time. We do. Sometimes we share them with other people. Yet the specific software for my business turns marked-up text into camera-ready proofs to print books. I'm happy to collaborate on a markup system, or a templating system, or a framework system for writing command-line applications which tie together a few modules into a pipeline, but the specifics of how I work aren't interesting to most other programmers or businesses.
I think that's a fundamental facet of Unix culture. We collaborate on low-level tools and utilities. We tie them together into specific, custom applications. That's no reason not to produce and distribute and collaborate at the application as well, but it's a reason why we collaborate at lower levels instead.
