The JWT is irrevocable by design, which is why it's time-boxed to a few minutes and not a few days. The refresh token is meant to be revocable. You the provider would store that in a database and remove it or mark it invalid when you need to shut the user out. So no, it is not simply moving the original problem around without solving it.
Most software devs using cookies would likely struggle to revoke an individual cookie - you can certainly architect that in, but if you're like most of us, nobody thought about it early on and now it's kinda problematic to retrofit. Same reasoning: "Well, it will expire on its own soon enough." JWT's actually make it easier to guarantee expiration since it's part of the token itself instead of being reliant on server-side mechanisms.
It's definitely a pain in the butt to juggle refresh tokens & access tokens as a client-side dev, and almost everyone's API docs are ambiguous and confusing about token lifetimes (refresh tokens often have lifetimes too). But that's another issue.
Again: If we decide to use cookies instead, we also need to architect in a Cookie Revoker to fix the same problem: That means tracking cookies against user accounts on the server side. I'm sure some folks have done this, but I don't know of any common frameworks that actually support it.
Most software devs using cookies would likely struggle to revoke an individual cookie - you can certainly architect that in, but if you're like most of us, nobody thought about it early on and now it's kinda problematic to retrofit. Same reasoning: "Well, it will expire on its own soon enough." JWT's actually make it easier to guarantee expiration since it's part of the token itself instead of being reliant on server-side mechanisms.
It's definitely a pain in the butt to juggle refresh tokens & access tokens as a client-side dev, and almost everyone's API docs are ambiguous and confusing about token lifetimes (refresh tokens often have lifetimes too). But that's another issue.