As you may be aware, we have tightened up password-less access methods in the past. We modified authentication code so that .rhosts was not honored for other users or from hosts which we did not trust. And we never put hosts in hosts.equiv which we did not administer. The reasoning behind this was that a compromise on an untrusted machine could be parlayed through these mechanisms into an account on our machines.
While public key authentication uses strong encryption algorithms to verify who you are and encrypts traffic over the connection, the private key, which is all you need to prove identity, is only protected by a pass phrase chosen by the user. The documentation suggests you choose a long, relatively meaningless pass phrase for this, it enforces nothing. Not even a length requirement. Human nature being what it is (and I've seen some of the passwords users have chosen in the past when did not enforce some kind of complexity on passwords chosen), some people will choose short, guessable pass phrases. Some will even choose an "empty" pass phrase, so they can just hit return when prompted for it. (We have in the past come across "root" accounts on user administered machines with no password!) It's likely that those who take such care in protecting their private keys will also be neglectful in keeping their machines current with security patches and updates. We cannot leave our machines continuously subject to the security decisions of all our users!
But completely disabling public key authentication places our users at a great inconvenience. Each time a new connection was established, the user would have to retype their password. In some cases, such as checking in a set of files to a CVS repository, this could be many times! We discussed the issue at an LCSR Users Group meeting and reached a compromise. We would allow public key authentication for a relatively short time, but long enough so as not to be a burden on the user. The period of 8 hours was agreed upon. In order to prevent the user from repetitively using the same key pair, key pairs would be issued by us. The public key would be stored in a place under our control; the private key returned to the user to be protected as they see fit. To limit the lifetime, we would periodically scan the public keys, removing any older than the specified period.
But even unprivileged access grants an unwanted visitor much more access to files accidentally or deliberately left unprotected to the user community of the system involved. And the compromised user may also be a member of a group for file maintenance. An intruder would then be able to modify or delete any shared files.
Also, many root compromises require local user access to attempt. No system, even one fully patched, is secure from all attacks which exist. We'd rather keep unwelcome visitors out than rely on security once they're in.