From what I've read (including BengalsUF's comments, which seem to be the only authoritative source for the case), it sounds to me like Mr. Childs was taking extreme security precautions.
It's been mentioned several times that the network devices were configured to not store their configs in NVRAM or to wipe the configs if password recovery was used. I personally think that is a bit much, but I could see people I've worked with over the years arguing for this in order to prevent the configs from being retrieved by an attacker (and then analyzed and used to attack the rest of the network).
So once you've gone that far, you have to have a way to legitimately store and reload the configs when the inevitable failure occurs or an update is required. But if you just put the configs in CVS somewhere, then that becomes the security hole people can attack. So encrypting them and requiring multi-factor authentication to access makes a certain amount of sense.
As I said, I think it's going a bit far, but if you really really really want to ensure security of a critical piece of infrastructure, that's one way to do it. The way Mr. Childs went about it didn't scale beyond him (another common failing in small environments where the team size = 1), and maybe was too limiting to really be practical, but I don't necessarily think it equates to a matter of ensuring job security as has been claimed.