Oi Rubens, tudo bem? Acho que algumas podem não terem ficado tão claras. Vamos a alguns pontos.
Quando temos sessão, além de guardar os dados da sessão de cada pessoa, também temos transição de cookies do navegador, só com esses cookies o servidor consegue saber qual sessão pertence a qual usuário, basicamente. E é um dado de sessão por pessoa, 5 pessoas, 5 cookies, 5 espaços de dados de sessão são usados. Outro detalhe é que se você duplicar os servidores da sua aplicação a sessão fica prejudicada por que um servidor pode não ter os dados de uma sessão específica. Neste último ponto, tem formas de resolver, como por exemplo, guardar os dados da sessão em um servidor separado com um banco de dados em memória assim todos os servidores podem obter os dados da sessão de um só lugar.
Por outro lado, temos os token...
Quando temos os tokens, os dados que importam para identificar o usuário ficam no próprio token, não precisamos de espaços de sessão para cada pessoa, pois cada requisição identifica e leva os dados do usuário então, 1 espaço na memória pode ser usado para descobrir quem são as pessoas com sessão ativa. A conta não é bem exata assim, mas serve de exemplo. Você perde a necessidade de ter cookies transitando de um lado para o outro e no caso de você duplicar o servidor da sua aplicação, você não precisa se preocupar com a coisa da session, por que os dados estão no próprio token.
A senha do token estarão em ambos os servidores, sim, mas é um valor tão pequeno que normalmente a gente não pensa no custo dele.
Indo mais além, tem alguns cenários onde você pode ter um serviço externo que autentica os usuários, então ele pode ter a senha e ninguém mais, os demais podem pedir pra esse outro servidor, os dados da sessão prontos.
Ficou mais claro? Com certeza devem ter mais pontos que eu não estou lembrando no momento, mas por hora, consegui pensar nesses. Espero ter ajudado, bons estudos!
