And command the corresponding salary and job security.

Well, i can't say about the salary (i get the average what my other IT colleagues get), but yes, working on in house Perl projects certainly increases (my) job security.

Code written and maintained by me runs on a lot of systems, from our central assembly line webserver (118000 lines of code and counting) to things like glue-code in our pay-per-page printer accounting, data syncronization across windows domains, a tool used by some to convert propritary VCard-files exported from old phones to CSV files, custom time syncronization code used on some assembly line systems to a windows service that restarts other frequently-crashing windows services on some too-expensive-to-replace non-updateable Windows XP boxes. And about 30 or so other small projects.

Quite funny, i'm still a one-man-team. Job security is fine. Going on vacation knowing someone would be able to cover for me would be nice, too.

You could get a lot of jobless Python guys around here who may be able to whip up a decent helloworld.py in a day or two. But all the Perl guys and girls i know have a good, secure job and not a single reason to join my company, it seems.

Maybe the design of the Perl language, its flexibility and its community play a vital part. When the assembly line stops and the german high end automotive producer calls every few minutes to get an update, you want a quick fix solution. But when most developers in these parts either learn Python or Java or something like this and have years of university "experience" and practice on how to design, implement and test a "good, clean, extensible and reusable" solution, being the companies odd Perl hacker who can "CPAN-hack a solution" in a few minutes (it only has to be just about good enough to get things moving again long enough to satisfy the customer) has its benefits...