Advocate-of-the-devling re: "something still needs the secret" (assuming you're symmetrically MAC'ing, not asymmetrically signing): yep, but that can be a tiny, separate component and that might be better than everything seeing the plaintext secret.
I wouldn't recommend such a scheme by default, because now e.g. your API clients are way hairier to write (e.g. serialization, possibly canonicalization) and it's pretty easy to mess this up (AWS did in their first attempt). But if you have resources to do it well, that is: audit the heck out of the protocol and the tiny component that verifies the MACs, it does prevent some problems mentioned such as unintentional disclosure of the key on the server side, replayability of requests. I don't think those are super valuable properties, but it's also not intrinsically a hare-brained idea.
TL;DR: API keys are fine and you should use them but you're not a bad person for wanting to HMAC things :)
I wouldn't recommend such a scheme by default, because now e.g. your API clients are way hairier to write (e.g. serialization, possibly canonicalization) and it's pretty easy to mess this up (AWS did in their first attempt). But if you have resources to do it well, that is: audit the heck out of the protocol and the tiny component that verifies the MACs, it does prevent some problems mentioned such as unintentional disclosure of the key on the server side, replayability of requests. I don't think those are super valuable properties, but it's also not intrinsically a hare-brained idea.
TL;DR: API keys are fine and you should use them but you're not a bad person for wanting to HMAC things :)