> If you need to be able to revoke stateless JWT's, you probably shouldn't be using stateless JWT's in the first place, because you'll have to re-add state to the system to handle revocations. And at that point why not just go with the simpler mental model in the first place.

Because you can speed up the normal app path by using stateless access tokens and only require online validation to issue new access token.

> And since giving users (or you) the option to "log themselves out of other computers" on a fine-grained basis is often an important feature to provide, it essentially means stateless JWT's aren't a great solution for sessions in most web apps.

The 'stateless' tokens may have arbitrarily short lifetimes, e.g. one or five minutes.

An app may issue multiple requests per second or minute; there's a speedup if those requests don't require online validation. Moving validations from multiple per second to once per five minutes saves a huge amount of system load.

It's an economic tradeoff between the costs of incorrectly giving access and the cost of performing validation for every access.