I think it was
JavaFan who told me he uses the idea of having cpan installation dirs writable by a special group, and told me it worked fine. Maybe we'll hear from him... (Update: he was even faster than me... read for yourself :-)
However, there is still a downside. Unless I am missing something in the documentation (am I?), the debian package simply calls the CPAN modules's own make files. That means that you are still dependent on the quality of the CPAN module writer's build scripts. If they have put in something that conflicts with the system Perl, one has the same problems as one would have downloading directly from CPAN.
First of all let me clarify that it does call the Makefile of the package via make install, with a special path prefix. I usually run dh-make-perl under fakeroot, so that it does no damage to my system if something is accidentally written to the wrong location.
There is a still the conflict with core modules, or for example when installing TAP::Parser 3.0 (I think) on Debian Etch it conflicted with perl core's prove utility. That's something that you can only avoid by using a separate perl installation independent from the system perl.
On my desktop I usually go the dh-make-perl route, and sometimes install a blead perl in /usr/local/ for testing. When I ran /usr/local/bin/perl -MCPAN -e shell I never had problems that modules where accidentally installed into / or /usr/ instead.
