How so? The client needs to have the username and password to call the login function over and over, as well as managing the session token. It's just incredibly annoying with no benefits in nearly every scenario.
The client should not store the user/pass [1]. If the token expires, the user needs to provide a user/pass to login in again. The user should also be forced to provide a user/pass in order to change the password - something that cannot be enforced if keeping the user/pass on the client.
You also lose any method to force a re-authentication. With a token, I could expire with no activity for an hour and allow it to be good for a max of 2 hours.
[1] Users have a bad habit of just leaving computers. With a token, the worst case is someone has a short lived access to to something. With a user/pass left on the client worst case now becomes use/pass taken.
What is the client? OP says API which sounds more machine to machine. If you mean the API powering a site, used from the client's browser, then sure. Track separate logins, then give them a control panel to see where they're logged in.
But most clients store their user/pass in their browser anyways so I'm not sure it's a security win for preventing credential loss.
You don't lose re-auth. The master system issuing API keys can revoke keys, too.
But anyways maybe we're talking about different contexts because I don't understand the scenario you're describing.
