That's a cool idea, I'd definitely like to add the ability to create a little store with more safety, and that totally works with the goal of simplicity. I'll give it a shot.
In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.
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).
Security only through obscurity is no security at all. The argument was generally made in the context of secret, proprietary encryption algorithms. In this context, it was frequently true - security reduced to reverse engineering.
But security isn't a thing. It is a property of a system. And many secure systems strategically employ obscurity for multiple purposes.
Reciting a mantra is a poor substitute for carefully considering your problem domain.