My team has had similar issues to which you describe. No CGI or html, but aside from that broadly similar. We have tended to go with a mixture of source control (source safe in our example) and CPAN packages. We tend to build a "project" in source safe that reflects our overall setup. Module bundles that make sense to be shared between projects are checked into projects with names like "lib-foo".

Now here is something to keep in mind, the part of CPAN package that you need is only the base stuff generated by h2xs (or equivelent) and any modifications and additions YOU make. Pretty much everything that gets left behind after you do a "make realclean". You dont need to check in anything that is generated by make/make test. Thus all the mysterious files and dirs you mentioned.

When we go to set up a project the first thing we do is install any "normal" CPAN bundles using CPAN as normal. Then we "get latest version" on the relevent unpacked private bundles held in CPAN. And run the install process by hand (make/make test/make install). Any modules go into bundles like this, ready for install later. All the rest of the project is then checked into sourcessafe "inplace". If you build your system appropriatly (and configuration system) approriately (we use a tweaked and extended Config::Inifile^*) a single change in the config file can handle a total relocation of the project.
*A useful addition we made was to allow for one config file in source control to be used on multiple machines of different configuration. This way key sections of the inifile can be made machine specific. This facilitates several developers working on different parts of the same project (with a shared INI file) on machines of different configuration. New stuff for the ini can be safely added to the common config file and checked out onto the various machines without worrying that doing so will screw up a given developers set up. And when changes need to made to these sections they are all in one place thus reducing the possibility of omission or other errors. Unfortunately the developers of the module rejected the patches we provided to them, so if this sounds useful you may need to reinvent the wheel. I could provide a patch I suppose. /msg me if you want.

For us this generally provides a flexible way to use source code control for both installation (installs generally amount to getting certain versions out of source safe onto the target enviornment, running the make process a few times and tweaking a few things), everything is under source control, and what makes sense to share is shared.

I delibertely wrote this before I read the other replys. Reason being that we currently have been doing cleanup and work in this very area (handling installs and source control) so its been on my mind lately. Thanks for asking the question I imagine that there will be useful advice from other people.