Beany sesyjne, czyli ThreadLocale podpięte do wątku sesji wykrzaczają się już przy pierwszym Futurze/ CompletionStage, które to działają sobie w innych wątkach. No chyba, że teraz jakoś inaczej te beany działają, ale nie wydaje mi się. Obsługa sesji zależy od frameworka. Framework może dostarczać wspomniane ThreadLocale i sesje przypięte do wątków, ale może zamiast tego np udostępniać sesję jako obiekt wprost.
Ogólnie jeśli frontend masz naklepany w jakimś frameworku SPA typu Angular, React, Vue itd to nie ma przeszkód by pchać koszyk na frontend, tak samo jak wszystkie inne dane sesyjne. Zwiększy to zdecydowanie skalowalność aplikacji, bo lekkie sesje nie będą tak mocno rozpychać pamięci na serwerze tak jak ciężkie sesje, a ponadto gdy zechcesz odpalić kilka instancji serwera to nie będziesz musiał synchronizować sesji między instancjami serwera bądź przypinać użytkownika do instancji serwera.
Swoją drogą to JWT + ich podpisywanie nie jest zamiennikiem dla typowych sesji opartych o ciasteczka + stan na serwerze. Ciasteczek i tak musisz używać, bo to jedyne bezpieczne rozwiązanie webowe, które jest wygodne dla użytkownika. HTML5 Web Storage nie jest bezpieczne, a jeżeli zrezygnujemy zarówno z ciasteczek jak i Web Storage to użytkownik za każdym przeładowaniem strony będzie musiał się logować. Zarządzanie sesjami po stronie serwera jest potrzebne, by móc te sesje zamykać. Nawet w Coyote jest opcja "wyloguj ze wszystkich innych sesji". U mnie w banku w aplikacji jest np wymóg, by dany użytkownik mógł być zalogowany tylko w jednej sesji jednocześnie - bez zarządzania sesjami po stronie serwera tego nie zaimplementujesz.
JWT można jednak użyć jako ciasteczka zamiast zwykłego identyfikatora sesji. Wtedy w JWT może być zawarty zarówno identyfikator sesji jak i identyfikator (np login) użytkownika (całość oczywiście zaszyfrowana i z podpisem). Potem identyfikatory żyjących sesji wrzucasz do Redisa i masz skalowalną i bezpieczną apkę.
Jeśli nie możesz przenieść stanu sesyjnego na stronę użytkownika to i tak w praktyce musisz iść na jakieś kiepskawe kompromisy, więc rozwiązanie nie będzie ani eleganckie ani przyjemne w kodowaniu.