If a malicious party has access to the API key, it should be revoked regardless

Of course. But I think the poster above was referring to just posting random keys to the server.

In other words I don't have your key, or any key, but I have "all of them".

The correct response to this though is that "there are lots of keys, and valid keys are sparse."

In other words the jumper of valid keys that could be invalidated in this way is massively smaller than the list of invalid keys. Think trillions of trillions to 1.

Which, like, if posting random keys has any realistic plausibility of collision, malicious revoking of keys is the least of your concerns.

People could just hit important data fetch endpoints with random keys, until they find one that’s good, and then have a compromised account.

Good point. Presented that way I am seeing more positives to their policies, in particular if a vulnerability was unearthed by the invalidation quirk it's a way better way to find out than any other way.

It's wrong that clients are authenticated with just the random generated username. But it's also what everyone do.

This is just a run-of-the-mill DoS attack, with the astronomically unlikely jackpot of additionally invaliding a random unknown user's API key when you get a hit.

Astronomically is an understatement. If they made 1000 requests per second they might have a 1% chance of revoking a key before the heat death of the universe.

Cracking hashing requires large parallel processing, something you can't do if you're API limited

If the API key is a UUID or similar in complexity, they'd have to send 5.3 undecillion API keys to make sure all of them were invalidated.

So yes, it would open the door to revoking random API keys, but that's not a bad thing; when using an API key, you should be ready to rotate it at any point for any reason.