[sweetjuly]

I think you need to take this a step further and really define your threat model instead of being despaired :)

If an attacker is able to steal a victim's cookie database, their system (or at the very least, their browser) is already deeply compromised. It is very likely that an attacker with such capabilities could prevent your website from ever sending the logout request (install a browser extension which blocks it, inject into the render process to silently drop it, modify the cached JavaScript on disk to inject code into the site, etc.). The logout functionality only works insofar as you trust the client, and in any circumstances where the client's cookies could be stolen you really can't trust the client. So logout revocation is not really a meaningful security boundary.

[johtso]

How about the scenario of a stolen device that's logged into the service. The victim logs in on another computer to try and reset their password and lock the thief out of the compromised account.

This can't be done without revocation.

[sweetjuly]

This is a different feature than a simple logout button though (something along the lines of "sign me out everywhere"), and many (smaller) websites don't actually support this. As far as I can tell, the very website we're on doesn't support it :) The parallel use case is SSO invalidation where you may need to immediately revoke access to a service after an employee is terminated.

You would need revocation in this case. Implementing this is easier when you already have database backed tokens, but unless you intend to support these features JWT is a totally reasonable engineering decision.