Yes, if you issue a long-lived token, you cannot normally revoke that after-the-fact but that is the point of the token, to avoid multiple lookups to an auth service for every single API access. In a distributed/scaled/microservices architecture, this would be unmanageable.
Now people often proffer some kind of backend system to try and maintain expired lists etc. but what is the problem you are trying to solve that couldn't be mitigated with a reasonably short-lived JWT like 1-2 minutes? Issuing a new one every 2 minutes while the user needs to do something is relatively painless compared to, perhaps 100+ calls to APIs each needing an auth call in the same time.
When you logout, the tokens should be deleted by your system. If someone copies the token before it is deleted, then they had access to the system anyway so that doesn't present a risk imho. If they gave the token to someone else, they are delegating their access so they lose out.
All of that said, if you do not have a heavily API-based system, it might be easier to just use creds that need checking with each call and do it the traditional way.
I have no idea what you are talking about here, can you explain this?
I work with systems that have a minute expire time. The only issue is that the clocks on all clients should be in sync with the auth server.
The only way I know of to implement instant revocation in a system like this is to keep a blocklist of users/tokens that is constantly checked, which can be slow and removes some of the benefits of JWTs in the first place (that they carry all the auth information you need).
Keeping a blocklist seems unnecessary to me, you can just lower the expiration time.