I prefer that as well.
I have seen some people shy away and am curious why.
Also, some people have situations where they are “fitting in” to
an existing setup where they just have passwords.
In this case, the automated setting up of keys between two remote machines (and tearing the setup down after, reliably) strikes me as too complex. Since we’ll be using Ansible for automated integration testing (which might include fresh, virgin VM snapshots), we’d really like things to be as automated as possible. SSH agent forwarding looks great (wasn’t familiar with it until the poster above mentioned it), but as far as I can see it requires both key auth and using ssh-agent (and some additional configuration), which I can’t necessarily impose on either our integration test setup nor on the guy who’ll eventually be executing the deployment playbooks on client premises.
I realize passwords are less secure and more cumbersome to use, but they simply fit our current requirements better. Yes, there are things we could do to transition away from using passwords (and maybe we’ll do them in the future), but right now, passwords work for us.
Solution is to not tear those keys down 
ssh-copy-id is a pretty useful program, though it's even better to
deploy them at provisioning time, which also all cloud solutions make
/super/ easy to inject keys.
I see your point; just as now we have VM images with a preset password we could have VM images that trust a particular key, or deploy a particular key using the password as the first step. We just down atm, due to lack of resources/education/whatever.
As for tearing down keys, if we’re talking about ansible → hosts communication, sure, I’d be fine with leaving the hosts trusting a particular key. If we’re talking remote machine → remote machine (i.e. Postgres slave → Postgres master), I’d really like those two machines to not have a passwordless SSH connection between them outside of the short deployment time.