I think there are some good points here, but I would argue that a lot of these are essentially points for hiring more junior engineers. There are cases where hiring for what someone already knows DOES matter.
I have come across too many codebases that were clearly written by folks who were in the "get stuff done" mentality. Frankly, when you're learning a new technology in addition to trying to do your job, your code/architecture just isn't going to be that good off the bat. If the company had instead hired someone who knew what they were doing from the get go, they could have started with a more solid foundation and potentially avoided pain down the road.
IMO this is a red herring. Even ignoring shifts in language and such, I'd imagine/hope that just about everyone would cringe a bit if they looked back at code they wrote some time in the past. It's natural - we're constantly learning and constantly improving.
I've changed languages multiple times in my career and yeah sure, one isn't writing idiomatic code right away but with a little breadth of knowledge and armed with modern tools such as stackoverflow it's really not a long transition period. If you add in a strong team and a strong culture of code reviews, the really egregiously non-idiomatic code will never make it in the codebase anyways (not to mention, the newbie will learn along the way).
Is that a problem of not knowing the language or a problem of not having exposure to better patterns [1] that are generally language-agnostic? I get what you mean about the idioms of some language: code is easier to maintain when it looks like what others on the team are accustomed to. But if that's the problem we're trying to solve, isn't that what initial code reviews of new team members can help resolve, among other things? And isn't that a benefit to hiring people who know other languages well? that they bring in new perspectives and ideas, such that the whole team can grow, over time learning and incorporating those new patterns?
Personally, I look for people who can think, who have exposure to a variety of patterns and can synthesize those patterns into their work, making appropriate choices. More power to us if, for our Perl shop, we hire someone with a strong background in modern Fortran because that different perspective is part of what makes the team diverse, creative, and successful.
I don't look for an expert in Perl to be even a senior developer here. It helps, but the primary consideration is their ability to work with abstract information. The language is just one of many tools to express that solution, and the language choice can change over time to suit needs.
[1] Not to be confused with "design patterns". I am using the term more fundamentally.
No really. I was hired in my current job 3 years ago, with experience. I didn't know Django, but had read enough, and seen a talk on it by someone else. I learned Django on the job, but my previous knowledge of databases and Perl complemented that. I didn't know Python, but its similar enough to Perl, I just googled to find the Python equivalent. Once you have a seen a couple of languages and concepts, learning new ones doesn't always hinder you so much.
I have come across too many codebases that were clearly written by folks who were in the "get stuff done" mentality. Frankly, when you're learning a new technology in addition to trying to do your job, your code/architecture just isn't going to be that good off the bat. If the company had instead hired someone who knew what they were doing from the get go, they could have started with a more solid foundation and potentially avoided pain down the road.