I think there are several advantages to breaking up the lotsa-modules structure you have

• you get to think about exactly how all the parts relate to each other
• whilst they may not be candidates for CPAN, you can create localised 'general' modulues - I find I end up with three groups -
  1. core
  2. tools/utils
  3. specials
• there are opportunities to refactor/simplify
• your release process can be better defined - this release is based on fixes to library A and extensions to library B, instead of we changed a whole bunch o stuff
• because the libraries are separated, one would hope that over time opportunities to use some of them for other projects would emerge - if they are all in one, that step may not be made
• it shows a level of maturity in your's and the codes development

As for the versioning I use the $VERSION string too, but sometime I even create a VERSION.pm file for a library, whose only job is to hold the master version identity of the library. I sometime link this to the CVS version support via

$VERSION = sprintf("%d.%2d", q$Revision$ =~ /(\d+)\.(\d+)/);
[download]

or I link to a tag holding the master version identity in CVS via

$VERSION = sprintf("%d.%2d", q$Name$ =~ /(\d+)_(\d+)/);
[download]

Be aware that $Name requires you checkout with -r <tagname>, and that CVS doesn't allow you to put '.'s in tagnames, that's why I use the '_' character.