Were I on the inside, here would be my reactions.

1. Moving from 5.005 to 5.6 involves internal testing of the existing scripts. That is a project in and of itself, and until that evaluation has happened you don't have a deliverable if it doesn't run under 5.005. (Hopefully they do have a plan to do that test. But you should not be driving their schedule.)
2. Get your modules out of the web area. Unless you have put them through a security audit, you don't know whether they have holes. If you have put them through that audit then you only think you know they are good. In case they are discovered to have holes, you don't want their use advertised. Only give out that kind of information on a need to know basis.
3. Perl does not recursively search the dirs in @INC. That is why the Perl person said to both put them there and then use lib so they would be picked up. But see my previous security comment and move them to an absolute location outside the web tree. Then use lib for that location.
4. Meshing versions might or might not work. It won't with XS code. Pure Perl code is generally forwards but not necessarily backwards compatible. If that is not an issue then you will have less work to do getting your code to be a deliverable for the actual environment...

Harsh? Perhaps. But it is your job to deliver code that works as well as possible in the target environment. Every release of any major piece of software has new bugs. Testing it before putting it into production is simple due diligence. Certainly at this point they should be scheduling when to evaluate an upgrade. But if they have a significant amount of Perl code, no decent admin should be willing to upgrade perl willy nilly.