You may only need 10 bytes of info, but that JWT is a lot more than just a data blob. It's a signed set of user info. If you don't need that extra layer, sure, then drop to an opaque token. Complaining that a signed header is large, however, seems a little silly. It's also worth mentioning that HTTP/2 also does header compression which helps with this.

An organization I was at in the past attempted to use them as a replacement for sessions, which turned out to be a terrible idea as I suspected it would.

I've found that arbitrarily re-inventing the wheel because a new thing becomes popular should be done deliberately and with great caution. More generally - I think it's important to look for solutions to fit a specific problem, not problems to fit a specific solution.

However, back to JWTs - I'm currently using them for authorization in an EXTREMELY high traffic websocket server implementation. It's really nice because it's short duration (the ones I am issuing have a expiration of 60 seconds), and allows the service to operate entirely within memory except for interacting with a Kafka cluster.

Author. I wouldn't recommend to do less than 2-5 minutes. Some OpenID Connect providers actually ignore token expiry time silently when it's below a couple minutes.

Consider that host clocks are not always in sync (even NTP could leave 10 seconds of difference) and the many authentication redirections can take quite a bit of time for slow clients. Limiting tokens to 30 or even 60 seconds is asking for troubles.

But then again, I have to work with thousands of hosts, applications and datacenters, so I feel every edge cases. A single application on a single host would not.