How does it matter how many tokens are in the blacklist?
If you're authentication something internal to a company, like the link between the website and the order status backend, there may be literally one user with one token.In this case, the list of revoked tokens will take little space, and update very rarely!
If you're authenticating users logging into your website and you decide user logouts should be implemented by token revocation, you're going to have a great many revoked tokens - perhaps within an order of magnitude of the number of active users you have.
I suspect a lot of the disagreement here is between people who are thinking of different situations.
For that reason I don’t know that it’s fair to say the disagreement throughout this thread is due to people talking about different things. Microservice authentication notwithstanding, session management is not optimally handled by JWT.
If the token blacklist is budgeted and never allowed to grow to a size of more than say 10-200, then it can probably be safely maintained over the lifetime of the project in a way that doesn't require a round-trip, in the source code for the service or otherwise gated behind a release barrier.
I don't know if I agree with that (I've never implemented JWT) but at least I think I've heard of the idea that's how the architecture is supposed to be planned for JWTs.
The actual issue here is that a lookup needs to be performed at all. For every request, you need to pay the latency of one DB round-trip as well as maintaining code that does this lookup. And if you're going to do that anyway, why bother with this complexity of "stateless" tokens?