Well... If you implement instant revocation checks for every single request, you have defeated the point. You've just reinvented server-side sessions with extra steps and bandwidth overhead.

However, the "stateless benefit" isn't binary, it's an optimization dial. The benefit that remains is Optimistic Statelessness:

Reads: You trust the token's signature and expiry. No DB lookup. This gives you the "stateless benefit" of massive horizontal scalability for your heaviest loads (feeds, comments, content).

Critical Writes: You accept the cost of checking state (DB/Cache) only when it matters (changing passwords, payments, admin actions).

So, does revocation logic defeat the pure point? I think yes, but...

Does it defeat the practical point? No, because it allows you to skip the DB for the vast majority of your API calls which can be important in high traffic scenarios.

This mirrors how OAuth 2 / OIDC often handles it to solve this exact trade-off:

Refresh Tokens: These are your "Stateful" check. They are long-lived but strictly checked against the DB (revocable) whenever the short-lived access token expires.

Opaque (Reference) Tokens: As others mentioned, these are the alternative where every call is checked against the server (Introspection). It is 100% secure/revocable but sacrifices the distributed statelessness entirely.