Scale is relative, but...let's put it this way. If you're at the sort of scale where you might struggle to trivially use sessions at scale:
1. You'll know. If you're not sure you're at that scale, you definitely aren't. 2. You shouldn't be taking advice from Hacker News; go ask the large team of experts you've already accumulated about what works best for you. If you don't HAVE a large team of experts on staff already about operating at your massive, massive scale, then see point 1: You're not at that scale.
If you model your sessions as an acyclical state machine, you can quickly consolidate a single view of all sessions globally.
Beyond this, it's valuable to be able to scope sessions, invalidate subsets of sessions, create delegate sessions, provide an audit trail for internal support staff using session impersonation, etc.
JWTs can't give you a lot of the rich security behaviors that real sessions can, such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes. Or estimate user idle time.
Our roadmap has a big emphasis on improved session management and these are ideas we haven't considered and I'm keen to understand more.
You might want to invalidate sessions from a particular device, IP, or time period. Or, if you detect a user is compromised, terminate all sessions on their behalf.
You might want API and web sessions to have different properties, such as duration. Or limit access to certain endpoints based on device type.
You might have a mechanism to turn one session type into another so that your app can open a browser and have the user already logged in.
If your model has a superuser that has oversight into a lot of account-like views, you might want the ability to constrain it to a subset of permissions while handing it off to something else, especially if those sessions are longer lived. Or give it a subordinate view.
You might want to assign confidence intervals to sessions based on heuristics and ask for a second factor for operations that require a given score.
There's a lot you can do.
Can't you just use the iat claim to check for issuance time for this one?
It used to be a serious bottleneck for even smaller sites. But they also used to stick them in stodgy, table-locking storage engines in the same database as the rest of their application.
Times have changed and I really believe you can manage cookies<->sessions without too much overhead. And if you're willing to let a JWT have a 5-minute max life, you could similarly cache your session responses for 5 minutes.
Like all things, there comes a tipping point eventually. But it's not as early or as drastic as it once was.
...which would be my first WAG if I had to design it for scale.
Sites were at scale before JWT conjured up.