They're also the kinds of people who will use the same version of their tools long after they've stopped being supported, and then when you need one of those new features, or run into a problem that you can't work around, you have to drag all that stuff into the present, which is always a huge pain in the ass. And the kind of developers who got you in that situation in the first place will be the least well-suited to help get you out.

Regardless, I don't think "I don't want knowledgeable people because they might write something 'too clever' that causes problems in the future" is a particularly winning strategy. You're basically saying you want dumb people because they will never try to be too smart for their own good.

They are absolutely the ones to create hard-to-debug issues because they layered a whole bunch of complex things incorrectly or unknowingly.

For example, recently I spent more time than I'd like finding out that we linked two incompatible versions of a library. All the visible dependencies were correct, but at some point someone bundled an old version in a fat jar and that got included transitively via another dependency. If you understand the details you know why you don't distribute libraries as fat jars. But if you're just following some guide it's easier to fat jar it than correctly specify your dependency tree.

If your education was really effective you recognize this is just the static/dynamic linking problem again in new clothes.

It’s true that clever code can only be written by knowledgeable engineers, but that doesn’t mean that knowledgeable engineers all write clever code.