Programming

The difference is that you can have multiple API keys for the same account.

1. You can revoke API keys from a lost device without changing your password.
2. You can grant a different service a restricted API key for limited access.
3. API keys can expire, forcing password expiry is very use unfriendly.

The password is the "root secret" of the account. It is (mostly) unrevokable and doesn't expire. It is a huge risk to have the password lying around. So it is better to quickly exchange the password for a less risky token, then you can wipe the password. Then all clients don't need to store the password. The user just needs to provide it once then lower-value secrets can be used for future authentication.

For what I see it'd be just like saying "using a password" vs "using a user and a password".

As long as API keys have more entropy than typical username & password combinations they can be more secure. Imagine if you had a system where you make a token by concatenating username and password - the security properties don't change just because you're exchanging one string instead of two separate ones.

It's fine as long as the key/secret is never transmitted in clear text (always encrypted e.g. with https) and never exposed to the end users to prevent credential leak. What matter is if you can rotate those keys quickly enough when there is a security incident. oauth has advantage here because the token has expiry date so if you happen to have a leak, at least the leaked token won't work indefinitely.

There is no difference security wise. The benefit of the clientid is mainly that it is shared cleartext information, so it can be used in eg. support requests, password recovery, what have you.