I hear this a lot, but I'm not sure I agree 100%.
I want to work with people who can write idiomatic code and are able to use a database efficiently (or who are at least willing to learn these things).
1. I've worked with people with years of experience in a language who can't (well, really, "won't") write idiomatic code in that language. This has—in my experience—typically come down to overconfidence/arrogance built on top of their experience whereby they've spent enough time with the language to develop their own "better" style.
2. Learning quickly on-the-job typically involved picking up idiomatic style first, before you really gain a deep understanding of the underlying workings. Ideally a good engineer should gain both, but at least initially, I haven't found the former to be a problem for "good" engineers starting out on something new.
3. For some language ecosystems, what's idiomatic changes over time. Flexibility and adaptibility is key to being a good engineer, but if someone has a lot of experience but isn't so adaptible (and/or hasn't brushed up on modern techniques in their ecosystem), this can also lead to non-idiomatic style.
I get that some of the things above should be red flags "in an of themselves" when hiring, but I'm just pointing out that a focus on past familiarity with tech can cloud things somewhat, and shouldn't be implicitly prioritised.