Issue tokens that have a reasonably short TTL - say, half an hour - and let clients use their refresh token to obtain a new token after that. On refresh requests, ask the database whether the refresh token has been invalidated, if it is, return 403 (bonus points for checking the expiration date first and delete expired and invalidated tokens from the invalid-list).

This reduces the necessary database roundtrips, while still supporting a logout flow.

This also means an attacker can be running around with a compromised token for up to a half hour before they're stopped.

If that is unacceptable for the business case, it's probably clear JWTs for sessions are unfit for the particular task?

Is it acceptable for any business to allow accounts to be compromised for a half hour?

I'd actually argue that yes, that is acceptable for more businesses than you might think. We're talking about a session staying usable after logging out for 30 minutes in the worst case.

For this to be exploitable, you'll have to jump several other hoops, like accessing localStorage of another application, for example.

I'm not the person you replied to, but in most implementations I've seen - they don't. Front end or app is politely asked to delete the token to simulate the user logging out, but the token isn't revoked in any meaningful fashion.

No additional checks are performed on the back-end to verify whether the token has been revoked as that would reintroduce a round trip to the database you're trying to avoid in the first place.

Well, when dealing with OIDC / OAuth you can bind the tokens to the user session or trigger back channel logouts. But anyways its not really easy to tell an RP to stop using a token.