Session stores are not public and are stored remotely on a server, hence rendering the session data to be safe. In the case of JWTs, the tokens are relayed on every request and can be intercepted. Sessions are, in most cases, safer than using JWTs

In what way sessions safer? Cookies just like JWT no more than a header attached to the HTTP response/request passed between a client and a server. If token can be intercepted, the session ID can be intercepted the same way. Once it is intercepted, an attacker can use it to have an authenticated communication on your behalf.

Having the session on the server side does not make it more secure. An attacker is not after the data in your session info, they are after your session ID/token so that they can communicate to the server "as you".

No sane person will put sensitive data inside JWT. They are meant to be open to public, although they allow for encryption if required.

When dealing with JWTs in SPA, often the solution is to transmit them in the httpOnly and secure cookie, which brings them in par with sessions more or less. Also, as soon as you add extra checks on the backend, like, blacklisting (like you mentioned) you essentially having implemented sessions :) except instead of an opaque token that represents session ID, you are transmitting a JWT that is open but has say a userId only in it.