Perhaps, but what they actually are is a standard way to encode some data. Whether that's a single number or entire user session state is up to you. And how you pass that data back and forth is up to you.
There are some common usage conventions but the limits described in this article are completely arbitrary.
Nobody here was arguing about what JWT is, the article is about how they're often abused in an attempt to obviate server-side persistent data storage in pursuit of "scalability".
The title is "Stop using JWT for sessions" not "Stop using JWT".
The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works.
If you want to say that client sessions should not be 100% on the client side and should be split between client/server then just say that. There are pros/cons but at least that is a clear argument instead of misleading about JWTs.
It seems you are overly defensive about an article that you agree in other comments is "not about JWTs" even though it is titled as such and talks about them at great length.
I think you can also see from my other comments that I know what I'm talking about and my issue is the fact that * instead of discussing client/stateless vs client/server shared state*, this article spreads more misleading information about JWTs and sessions.
Otherwise, they could just use a long random string and maybe HMAC it and call it a day.