I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.
This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.
I totally agree with that, in theory. In practice, sometimes teams can be spread too thinly to allow adequate code reviews, developers can have egos associated with their titles that prohibit constructive criticism, and management can favor "if it looks like it works, it works" style of project delivery. These real world scenarios bias me towards people who know the language they will be using daily.
