Seemingly we have also forgotten the pain brought by session cookies. Applications relying on session cookies typically broke when users opened several tabs and switched between them, users used the browser 'back' button or accessed the system with two devices simultaneously. It was difficult and required a lot of discipline to write a good application with session cookies. At least when you use them for more state than just authentication data.
I for one am very happy that we have passed the age of session cookies. That doesn't mean that everything is perfect now, but applications generally work better than they used to do before the JS+API pattern.
I think you're conflating something here. Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior, even when you use multiple tabs or multiple devices.
But I remember a time when especially bank websites added an additional token (like a super strict CSRF token) to their app, which tracked the current page of a user and if you browsed the same website from another tab, this other tab didn't have the proper token and the whole thing just returned "invalid user action" or something like that.
However, this has nothing to do with session cookies.
Typically, in the Weblogic days, session cookies were used to hold a server-side session containing the app state. If you just hold auth data in the session this is not a problem. But if hold state like form data in the session it becomes a huge source of errors. Virtually all non-trivial web-based applications had these issues 20 years ago (before „Ajax“). J2EE servers like Weblogic even supported stateful EJBs that brought server-side state to a new (insane) level.
While you could theoretically use JWTs for the same purpose, they are typically only used for authentication. And back then JWT wasn’t a thing.
> Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior
It does make a difference. The cookie is sent by the browser to the server, the JWT is sent in the Authorization: header by the JavaScript code executed by the browser.
Using an opaque JWT token wrapped in cookie is OK. Using a JWT token in the Authorization: header is not OK.
I for one am very happy that we have passed the age of session cookies. That doesn't mean that everything is perfect now, but applications generally work better than they used to do before the JS+API pattern.