If compromised, you can change an API key. The key is like a password, and keeping that secret is important.

Where the "obscurity" aspect comes in, as an example, can be through the mechanism used to generate and validate that key.

Let's say you decide you don't want to or can't store the keys, and don't want a full pki system (public/private keys or certificates), so go with: sha256(clientid + userid + "hardcoded secret"). Your security now 100% relies on no one knowing that algorithm. If someone figures it out, you need to release a new version of your software, invalidate ALL API keys, and for that effort you still haven't done anything to prevent the same thing happening again.

A good test of this is: if someone has your source code, can they break your security mechanism? If yes, you're probably relying on security though obscurity. By contrast, if you're using asymmetric encryption to generate keys, it doesn't matter if someone knows that: if they don't have the private key, they can't do anything. (This leaves aside the issue of storing your private key or other secrets in source code, but I'd describe that as an operational failure rather than a fundamental design problem).

If a cryptographic hash function is used, the security of this scheme doesn't rely on keeping the algorithm secret, though. Therefore, it's not security through obscurity. Of course, weaknesses could still exist (e. g. a too small input space because the ID that is hashed has too little entropy).

Security through obscurity refers to relying upon keeping the details of the security mechanism secret. An API key itself is a secret, but the mechanism for how that key is generated and used is public knowledge.

In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.