I've been doing the same due diligence and I too am concerned that all of the client tools and documentation seems to promote bad security best practices. I response to the question "do you really want to be reentering a pass phrase for every single command you enter?" -- yes, or at least I'm happy to have a tool like ssh-agent enter it for me. I don't ever want to find any of my private keys or pass phrases sitting around in plane text on my filesystem. I'm amazed that the standard response is just "encrypt your whole filesystem".
Even if I mount and encrypt just an .ec2 directory and stash everything in there, I still have to be careful not to follow the documentation which suggests setting my secret key as an environment variable in my bash_profile script. So maybe I just put it in a script on my .ec2 directory and pass it in on the command line -- oh wait, now my password is sitting in my history (I still can't believe os x isn't nice enough to skip storing lines that I prefix with a space). So really I need to encrypt my entire user directory just to be safe. And why exactly is it that the asymmetric process of using x.509 certs is being deprecated and replaced with the "secret key" authentication process? At least the former allows me to store the private key in a file -- the latter requires me to pass it in as an argument (the value of which gets plastered all over my history and scripts).
The problem is that there are all these great security protocols, but nobody wants to take the time to understand them. Instead they just want to get things to work -- as a result they blindly follow some step by step documentation that was written by somebody who blindly followed somebody else's step by step documentation. Nobody questions any of this because they don't understand it and they just want it to work. The result is the proliferation of really bad security practices.