What makes a key simple also makes it fragile
An API key is a static secret string, issued once and presented unchanged with every request. Its simplicity is genuinely valuable — nothing about implementing or using it requires much beyond checking a string against a stored value — but that same simplicity means it inherits most of the weaknesses any long-lived bearer secret has: it's easy to accidentally commit into source code, easy to log inadvertently, and typically carries no built-in expiry beyond whatever the issuing system chose to bolt on.
Because a key is a bearer credential, whoever holds a copy of it, however it was obtained, can use it exactly as the original holder could. There's usually no proof-of-possession requirement narrowing that down to the original, intended caller.
When the simplicity is worth the tradeoff, and when it isn't
For a low-stakes integration — a public read-only endpoint, a rate-limited free-tier API — the operational simplicity of a static key is a reasonable tradeoff against its weaker security properties. For anything where a leaked credential would be seriously consequential, the case for a token scheme with short lifetimes, explicit scope, and proof-of-possession becomes much stronger, and the extra implementation effort earns its cost.