They might have legitimate reasons for changing (the normal one being that they have a programmer on staff who knows some other language, and they don't have the time to maintain additional code ... of course, if that were the case, they wouldn't have time to re-write additional code, either).

Other legitimate reasons include wanting something compiled so that people can't as easily inspect the code, if it's something to be sold as a product, or to reduce complexity if the program has to interface with some other system that only provides language-specific APIs. There may also be issues with needing to reduce the execution time, memory footprint, or some other metric and they want to go to a compiled language for that.

...

Anyway, my typical issue is that if the code currently works correctly, there is the possibility of it not working correctly after the change. If they don't need to rewrite the script, it may be enough to have to documented to the state where someone else with only basic understanding of Perl can take over.

This is an initial savings to the company, as they don't invest more time to get to the same level of quality that they currently have. It can also reduce risk, as an incorrectly translated program may have defects in it ... depending on the project, that may not be acceptable (but if that was the case, they'd likely have better documentation).

One of the problems that I've run into, even staying within the same language, is that often the complexity is there for a reason -- handling edge cases, etc, and an attempt to rewrite the code might remove all of the embedded knowledge that the code contains.