If one can steal a token from your browser's storage or can intercept your HTTPS connection, then sure, yes, you have a huge vulnerability even without JWT.

You notice odd behaviour so you log out to stop it but the attacker isn’t logged out.

Also with this setup log out of all devices is not possible! Again something you’d be keen to do if seemingly attacked.

In OpenID Connect, there are back channels that talk to each other so that all devices know you have logged out.

If you are using traditional auth then yes, you would need to track session state against the user so that when they access from a particular device, you could check whether they have already logged out.

Some more complex apps use a background thread to check auth status with the server.

It isn't unrealistic at all. A lot of attack vectors seem unrealistic to the victim until they happen. How realistic is it to think that a hostile actor can inject their code into a build process without touching the disk, then get that corrupted executable signed; then that signed executable is installed by 18000 users with root permission?

If you don’t want to maintain a centralized session store and you don’t want long lived tokens just set the expiry to 90 seconds. When you attempt a refresh, if the user is logged out it will fail.

I’m really confused by the either/or of “hit central session store on every request” or “tokens that live five minute too long are bad mmmkay”.

That sounds like a very complex system to cache session tokens. You may as well just cache normal session tokens for 90 seconds in your application servers. Same result, less complexity.