For a counterexample, I hired this way for a long time.
Like you said, it works for university students because they don't have experience under their belt yet.
It becomes less effective as you get into more complicated languages/frameworks and you have less time to ramp people up.
In the worst case, we'd invest a lot of time mentoring people in a new language or framework and 6 months later they'd decide they preferred their old language/framework. They'd either leave the company to find a job that fit their preferences, or they'd become disgruntled and spend their days complaining about our language choice or trying to persuade us to rewrite in their preferences.
In other cases, people would try to write everything in the style of their previous language, even if it doesn't match the new language or framework.
It happened enough times that I now prefer candidates who already have proven experience in the language we're using. I won't exclude candidates who don't have experience in it yet, but it's rare that I'll pick a decades-long Python programmer for a Rust position, no matter how much of a Python wizard they are, as long as we have good Rust candidates in the pipeline.
The only exceptions I can think of are where you're hiring someone specifically to work on language tooling - e.g., to work on the core C++ library team at Google, you probably need some experience with specifically C++ or C and compilers thereof. Those would be very specialized senior roles, though.