Este foi um detalhe importante para saber... Então, dados sensíveis, não são interessantes de serem inseridos neste token, né?

Exatamente. Você pode encriptar o conteúdo ou utilizar o JWE (Json Web Encryption) caso seja muito necessário.

no meu caso, para autenticação, estou enviando o user_id e um pass (gerado aleatoriamente e o rash salvo no servidor), que são verificados a cada requisição. acha relevante a criptografia para este caso de uso?
Pelo que li dos outros comentários, esse hash extra só serve pra você fazer mais uma validação de segurança do token, você pode usar isso pra colocar metadados do token no seu banco, como a possibilidade de cancelar esse token quando quiser, por exemplo ao salvar no banco o hash e uma flag de válida ou não, mas se não for usar pra isso, é desnecessário. Ainda me parece que você não entendeu completamente a solução que o JWT traz. Você pode pensar no token gerado como um crachá que você deu pro usuário assim que ele entrou na sua aplicação, contendo o nome dele para que qualquer um possa ler, mas você também adicionou um carimbo que só você tem, então por mais que qualquer um consiga ler o conteúdo, apenas você é capaz de fazer aquele carimbo no crachá. Dessa forma, se você ver o usuário novamente você terá certeza que o nome dele está correto no crachá porque apenas você poderia ter carimbado daquele jeito. Edit: esqueci de responder a sua última pergunta, não, não acho que seja relevante porque o user id não deve ser um dado sensível.
entendido! complementando a analogia, é como se o crachá dado ao usuário fosse feito em um cartão magnético, que, dependendo da sensibilidade do que ele pretende acessar, eu posso gerar mais uma validação. já estou conseguindo entender a utilidade sim... mas para a natureza da aplicação que será trabalhada, é exigido o máximo possível de segurança para alguns endpoints, por isso pensei em mais uma camada de segurança. quanto ao id, realmente não precisa ser considerado sensível...