1) To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff

This is highly dubious, the tough part of coding is getting the algorithms right, the language is just the way to tell the computer what to do. How far should this be taken - arguably you should continue and specify particular frameworks, tools, IDEs etc. You'll end up with code by numbers.

2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.

ie - it ain't perty. This is often a problem that I find - people who do not code do not like non GUI interfaces for lots of reasons - mainly lack of hunt and click. That document might want a bit of critique. There will be some valid points but if your team can't work as a team then it is not a team.

3) There's nothing you can do in Perl that you can't do in Java. This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.

There's nothing you can do in Java that can't be done in perl... There is also an important distiction between execution speed and develepment speed. Also consider development time to lifetime ratio - very important.

4) In fact with the new design reviews, any Perl implementations will not get past that gate.

Hmmm, unable to comment.

Good luck fighting this.