I don't think your example (or even your problem) has anything to do with the language, or the way it's used. Your example would be exactly the same if two Java programmers worked on the same code base, and one of them used Spring, but the other had never seen it.

Not being interested in programming outside of work is no excuse for doing a poor job. As part of being a good programmer, you should keep up with the latest technologies, methodogies, techniques, etc. These things change very quickly, and if you don't keep up, you will be left behind.

If you really don't care about keeping up, that's fine, but you will never rise above the rank of code monkey. Any organisation who wants quality code should make sure they don't have code monkeys in charge. It's ok to have them on board, but they need to be working under the guidance of senior, experienced developers, who have a good understanding of various development practices (e.g. some degree of Pair Programming would have prevented the problem you describe occurring).

Even beyond that, a good programmer should have no problem reading, understanding, and changing code that's at least written to a reasonable standard, regardless of whether they'd seen code written in that style before, or even in that particular langauge.

The main reason why Perl has a reputation for producing poor code is the following logical fallacy:

1. Perl has less restrictions built into language than other popular languages (e.g Java, Ruby, etc), therefore:
2. It's easier to write unmaintainable code in Perl, therefore:
3. All Perl code is difficult to maintain

Basically, people assume that because Perl hold's the programmers hand a lot less than other languages, that there's no way anyone other than a genius can write good code. (TIMTOWDI is part of that, the specific merits of which are a completely separate discussion, IMO).

Hand-holding might be fine for some people, but as I outlined above, you will never get good quality code without some experienced, capable developers around. (This is not just my opinion either, many have written about it in the last few years). These types of programmers do not need their hands held. In fact, they much prefer full flexibility, because they're in a much better position than the langauge to decide when they should use some part of the language that can be dangerous. They can also be the ones to hold the hands of their junior devs / code monkeys, again replacing the language. Surely they're going to be able to do a much better job than a language designer who has no idea what the problem domain is, the various skills of the dev, etc. etc.

In the end, programming langauges have never been, and should never be, one size fits all. A lot of the Perl sniping boils down to just that: people don't want to have to learn something new, beyond what they already know well, so they wish less mainstream things like Perl would just go away. Sometimes hand-holding is good, sometimes it's going to make life difficult. It's good to be able to choose.

So basically, no, I don't think TIMTOWDI is anything to do with Perl neccessarily producing unmaintainable code. It's just another argument that's raised (along with regexes, dynamic typing, flexible OO, etc.) by people who've never worked on a well-run Perl project.