Protecting sunk costs is only a fallacy if the money was entirely wasted.
If you spent money on something and that something isn't worth what you put into it but still is worth a lot, you want to protect that investment.
As far as incremental improvements go, rewriting some part in another language seem pretty bad. I mean, if you are being incremental, then you have to make changes that might interrupted in the middle and then you'd be saddling the system with two different languages.
You could just easily rewrite the worst parts to conform whatever existing or new standard you have. I'm not fan of Perl but I'm pretty sure you could at least create a subset that would conform standard object-oriented practices and not have the problem of now having a system written in two different languages.
I have a hard time considering this large application as an "investment". Presumably, it provides some business function, and has been hopefully generating more revenue in its lifetime than was spent creating it.
I don't think the software has any intrinsic value; it wasn't constructed from precious metals, which could be re-smelted and sold for scrap. If continuing to develop it/maintain it is costing them money (either in real terms because of development costs, or by lost opportunity costs), than they should look at how that's trending. At what point does the thing cost more than it's worth to them? (Maybe it never does, I've had banking customers who spend millions of dollars a year keeping a thirty year old, p.o.s. Cobol application running because it's the backbone of their operations).
And I didn't mean to imply that they should rewrite parts of it in another language, just that they should start decomplecting pieces of it so that they can replace those pieces with better-designed ones. If they want to stick with Perl, because that's what their expertise is, than I think they should do that. I would agree that it's probably counterproductive to take on both rebuilding the application while at the same time switching to a new language.
But unless the entire application is passing around internal Perl data structures, it seems crazy that they can't identify edges to the application functionality, and start to peel those edges away and encapsulate that functionality in a better way.
If you spent money on something and that something isn't worth what you put into it but still is worth a lot, you want to protect that investment.
As far as incremental improvements go, rewriting some part in another language seem pretty bad. I mean, if you are being incremental, then you have to make changes that might interrupted in the middle and then you'd be saddling the system with two different languages.
You could just easily rewrite the worst parts to conform whatever existing or new standard you have. I'm not fan of Perl but I'm pretty sure you could at least create a subset that would conform standard object-oriented practices and not have the problem of now having a system written in two different languages.