Pros / cons of using password-less OpenVPN client keys

To respond to each of your points:

1 - You are correct in analogizing the password protection of OpenVPN keys to password protection of SSH keys.

2 - Without using any additional authentication method OpenVPN relies only on the verification of the client certificate by the server (and ideally verification of the server certificate by the client) for authentication of the client. This makes revoking an individual client's access a matter of either adding the client's certificate to a certificate revocation list (CRL) (supported by versions 1.5 and up of OpenVPN) or removing the key material from the client (or switching up the certificates on all your other clients). If you're not using an additional authentication method you need to have a CRL to allow for client access revocation.

Keep in mind that password protecting the keys doesn't help you at all re: additional authentication. That password just "unlocks" the key on the client device-- it doesn't alleviate the problem of additional authentication of the user on the client to the server computer (and the access revocation problem).

3 - You should generate the private / public key pairs on the clients themselves, as opposed to transmitting them over the wire. You can generate the certificate request on the client, send the public key (in a Certificate Signing Request) up to your CA for signing, and install the signed certificate on the client. This could all be scripted, and I'm sure somebody has already done it (and I'd hope that the commercially licensed OpenVPN product probably has some of that functionality built-in).

I find this My Certificate Wizard project that was written just for this purpose, but I'd go for scripting the entire thing on the client using the OpenSSL command-line tools in an attempt to make the entire process mostly invisible to the user.