There are certainly a lot of things about Perl that are unique, but some time with the camel book and a few weeks of practice should sort that out for anybody with several years of production experience in another language.
Evaluating true and false, or just simple comparisons, can be a mystery. Heck, just figuring out what's going to be a syntax error or not depending on if a variable was declared, defined, interpolated. Or referencing a nested data structure when one of the elements doesn't exist. Even just general conventions and best practices fills its own O'Reilly book. We haven't even begun talking about regular expressions.... Then there's the autoloader, and constants, namespaces, scalar/list context, signal handling, ....
Part of the difficulty of Perl is that you can write code that works perfectly until the clearly-obvious hole you left is triggered and a fatal error occurs, and then you get to learn about the debugger. It takes years to use all the parts of Perl that have weird magic or complex, non-obvious functionality tied to them. Saying you could use it all without problems after only a few weeks is really misleading.
The fact that there is a "strict" mode at all speaks to how difficult it can be to get the language right.
But, evaluating true and false in expressions is tricky in a lot of languages now. PHP is notorious for it. That's why you shouldn't mix data types. Regular expressions are no longer the sole domain of the Perl hacker, they're a regular staple of JavaScript and PHP and the commandline and other utilities.
Look, here's the thing: the response to avar has pretty much been, "you guys are doing it wrong", which is a seriously uncool armchair quarterback thing to say to someone else, especially someone that's a part of something as big as booking.com. If in fact their hiring process was as unutterably broken as you seem to believe it is, wouldn't you've expected their business to collapse in a pile of inscrutable bugs by now?
I'll readily agree that there's a vast difference between a coder in any particular language, and an expert in that language. That's why the experts get to define the language conventions used by a business, and the coders get to follow them. That's why there's testing and debugging and staging.
I try to assume least level of incompetence in other people on HN. Maybe instead of declaring things about their code base that you have no actual knowledge of ("There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase."), you could instead ask, "How do you guys handle training the guys that aren't very familiar with Perl quirks like int@_ vs $#_?"
And i'm not assuming any level of anything. If you learned spanish in Spain, you can't just go to Mexico or Venezuela or Argentina and pick up the local dialects, because there's different grammar and vocabulary and pronunciation you won't know until you run into it. Trying to write a paper in those countries after only using their dialect for a few weeks will land you with mistakes. I don't think this is a controversial thing to say. (And this is assuming you're picking up a very similar language; trying to go from Spanish to Portuguese would be nearly impossible in just a few weeks)
>>which is a seriously uncool armchair quarterback thing to say
Imho, you read too much into the discussion. Everyone knows that Booking.com must be doing a lot of things right for their particular problem set and situation. It is a high profile place that attract good talent. (I am hardly alone in assuming they aren't too stupid to listen to Ovid et al.) Their situation is unusual and the resulting specific differences in methods will be questioned, because of their high profile.