This kind of life-span for a mainline Perl application is actually very common ... and there are of course a lot of programmers in the market today who were not even born yet (or they were but toddlers) when the systems that they are now being asked to work on were first made.

This, more generally, is the “legacy-code” issue, and this was the essential point of my (much-downvoted, of course) previous post.   It is not that the IT staff of the company in question is in any way clueless.   They know that the system now in-place is working, and that the company simply needs it to continue doing so ... which it will, unless someone decides to re-code the thing in Perl6 Java.   (You never correctly estimate either the cost or the true business risk of a re-write.)

This is also why I repeatedly advocate that you should write your source-code for the future ... because it will have one (even if you don’t ... watch out for bread-trucks next time).   The business value of your work is not tied to the language that you wrote it in, and the task of converting a mission-critical system, to anything else whatsoever, is fraught with costs and risks.   Lots of programmers in the business today simply have no idea of this.   (They are not, dare I say, old enough yet.)

Perl is not the only mainstream language today that is doing this sort of thing, of trying to radically reinvent itself under the same brand-name.   Python, PHP, and Ruby all did it, too.   Every one of them discovered that the “older, badder” versions did not disappear from service, because there was no business case to put existing business software assets at such risk, no matter how “–er” the new language-version might have been.   The contributed-software libraries which accompany all of these languages was the biggest part of the coffin-nail in that decision.