I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.
2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.
And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.
Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.
I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.
If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.
I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.
Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.
"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".
Did you bother to be honest with them about why you "rejected" these folks?
I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.
That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.
I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").
I'm not upset at you.
"I'm pointing out that if you're good, you don't need to worry."
Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.
The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.
Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.