For one a key is not transmitted over the network but the bigger reason is that most people don't use sufficiently long, random and unique passwords. If you are running a server where only you SSH in and you use a long random and unique password you are probably fine but for most people it's just easier to use keys at that point since it is not a lot easier to use long random and unique passwords than it is to use keys.

One upside to keys is also that since the server does not have your private key you don't need to rotate it if that server is hacked so you can reuse the same key for multiple servers and services. If you reuse the same long random password it only takes one of those servers/services to be hacked for you to be compromised on all of them.

If you plan to store your private key on a device you can loose the key itself should have a password too. So the attacker needs still a password to unlock the private key. This is actually a good idea in general. Securing the private key with a password.

passwords are a symetric key, hence if the server is compromised, so is the password. with asymetric keys, a compromise of the public key is no problem.

but you are right, key-files on a disk are more vulnerable to theft than secrets in your head. keyfiles with a password ontop are most secure but also most uncomfortable.

It's a good idea to encrypt devices you could potentially lose anyway. Besides private keys, they probably contain session tokens, API keys, and other things--especially those saved by the web browser (cookies, cache, local storage)

Use one key pair per device. If you lose the device, remove the associated public key from the server's authorized keys.

Using a password on they key isn't a bad idea either.