So it's fine for some services to serve requests after the access has been revoked for a few extra minutes or seconds.

For some it isn't. I have no say on the matter, I feel like security lax-ness makes sense for games, since jacking sessions with jwt is significantly less consequential and you have other sources to validate session health, such as route and ip address.

You can always revoke jwt if the ip address for which it was issue has changed or the route is different and so on and can be even more secure against forgery attacks.

Still not perfect and I find OP's take the it's good enough for banking to be sus.

But it's definitely not a scam, it's simple easy and trivial to use for a lot of low risk services.

You should build a map of low risk and high risk access and not use jwt for anything high risk, because jwts definitely provider better user experience for relatively less effort and resources and technical complexity needed.

What I did in the last systems I created:

1. The JWT expiration depends on the user. Admins get only 1 minute or so, but regular users 1 hour. If I had an SaaS for enterprise customers, I would use very short expiration times for paying enterprise users, but long for non-paying users.

2. When 95% of all requests are reads, and it's not sensitive data, only validate the JWT. For dangerous operations, always require validation of the user status.

3. I prefer to let the server control the JWT lifetime. So the server can respond to any request with a 'token too old' error, and the client knows it must renew it and retry. That allows you to configure the expiration date of the token depending on the operation and how critical it is.

Of course the only completely hack-proof device is a brick.