Generally you should try to tokenize your auth system. Passing "keys to the kingdom" directly to the API for each API call can cause a lot of grief in the event of a breach of one of your nodes. If you're using a tokenized and access-level controlled system with something like OAuth, the breach is bad - but it's temporary without having to run around trying to change creds over.

It's fragile: leaks the password when TLS is having a bad day, when the server's compromised—say, on more than 1% of days in the last five years.

It's fragile to request smuggling attacks too, because the password is not entangled with the request, just next to it.

We have lots of mechanisms that do better than both of those: client certs beat the first, and HMAC of the request and key headers with a secret beat both.

I think that the main issue is the client must send what is essentially the plaintext password on every request, meaning the client also must store the password. It might be short-lived, might not, but is a security risk to keep the password around on the client side for the duration of the session.