Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

Where I work, the company policy for C/C++ projects is to use #include "standard.h" where standard.h contains a series of #includes and definitions we are required to use. (We are allowed to modify the project specific standard.h to fit project needs.) The rational behind this is to provide a single file (in each project) for these items to be edited, thus reducing the opportunity for introducing inconsistencies and other errors into the code.

Doing similar with Perl (and whatever other languages used in the company) would be consistent with the spirit of company policy for C/C++ projects. (All of the production software in our products is written in C/C++. For "in house" tools, the language used is left to the creator of the tool. Perl, LabView and CAPL are most common for engineering tools; VB macros for "office tools").