Only your stupid strawman is ridiculous, I'm suggesting that if you WORK at a major bank and you are responsible for their backups then part of that is being able to do bare metal recovery AND walk others through the process.
Your argument was that some stupid intern you hired might not be able to figure out how to use an encryption key, so the process should be simple; then it was that keys and documents get lost, and you should be a good enough admin to know wtf you're doing; now it's that you have the whole process memorized, being the veteran resident expert on the business's particular system and having designed it from the ground up.
Let's refresh your memory:
If you can't successfully explain a recovery procedure to a recent average high school student over the phone then you are doing it wrong. If someone in ten or twenty years needs to track down a key from ex-employees that have moved or died then you are doing it wrong.
As well,
With respect - professional engineer here, guy with a HR granted title of engineer there. You really should choose your insults a bit more carefully. I'm sure you have plenty of skills I do not have but to me IT in general is a subset of what I was doing last century, so you have only succeeded in making me laugh by puffing yourself up.
In the last decade, we've moved on to virtualization, infrastructure as a service, and document stores like MongoDB. Last decade, when you were doing this shit, you probably had huge SQL relational databases, which are like collections of giant CSV files with indexes; those databases were a step forward from LDAP, a form of hierarchical database, basically a giant file system with tiny files; while document stores are basically giant collections of XML- or JSON-like data, with indexes. Routers are now ASAs, with 10 MICROSECOND switching while deep-packet-inspecting 26 gigabytes of data per second, thanks to using ASIC logic instead of general-purpose CPUs; switches operate on layer 3, analyzing IP headers, because why not blur the line between what is a fucking switch and what is a router?
Not to say that old skill sets don't found new skill sets, but we have managed to get rather dated here rather quickly. I've compensated largely by constantly collecting more information and keeping a broad knowledge base, rather than staying current in a single technology. Everything from financial systems to devops, from back-ups to system programming, has some level of competence on my skill sheet--some of them are very low levels of competence, some (like Unix administration) are such high levels of competence that I'm over-invested, to the point that I can use awk to impressive but wholly-unnecessary effect.
I branched out into project management because this is just too much crap to use effectively any other way, which is why I have comments on long-term planning, and particularly on risk management. Losing an encryption key is one of the most minor risks I can imagine, and every scenario you suggest is patently ridiculous. Twenty-year-old back-ups? A process that hasn't changed while the data center around it has undergone disruptive transformations? Keys owned by employees, rather than static in the back-up system and transferred off-site over key exchange protocols? People overwrite tapes every year in a cycle; your back-up process would not work if not updated to keep up with your data center's needs; and any such stupidity as poor encryption key handling would be projected early in the process, or else you're completely incompetent and likely won't have working back-ups anyway.