you can use signed cookies for sessions - which have none of the drawbacks you mentioned. i.e. session data and expiration form the payload, and you sign the payload - then you validate the expiration and signature on subsequent requests.
Solves some of the session problems..
Benefits:
Cookies - when set to http only + secure only are safer?
Drawbacks:
They're not cross-compatible No expiration baked in No not-before baked in Limited to hmac validation (no public key crypto options that I know of)
Unless you mean using a JWT as a cookie value. I guess that could work?
There are many, many implementations in use "in the wild". They are just signed payloads, so they can contain "expiration", "not-before" or whatever else you think isnt "baked-in". You can use any method of signing them, but would probably make sense to use a strategy that is considered secure :) No doubt the libs you mention can be extended trivially with this "missing" functionality.
Signed/encrypted cookies predate JWT - they even predate JSON...
Im not presuming that they are better/worse than JWT, just responding to the incorrect statement about cookie based sessions requiring server-side storage