Sobre o DELETE, eu faria exatamente como você mencionou, comparando o ID do usuário do JWT com o ID enviado na URL. Já vi pessoas com receio desse tipo de comparação por conta do JWT ser "visível" para o usuário (não diretamente, mas um curioso consegue ver ele no localStorage ou nas chamadas às APIs pelo DevTools do Chrome, por exemplo), mas como a estrutura dele envolve assinatura e etc, acaba sendo mais difícil de realmente comprometer a integridade dele, mesmo se alguém mudar o payload que é um simples base64. Se o seu back-end faz a validação certa do JWT, pode pegar as informações dele sem medo. Então, no seu caso, particularmente eu acho válido comparar o ID que vem no JWT com o ID informado na URL pra saber se o usuário tá fazendo "usuarisse" ou não kk

Sobre o código de retorno, eu particularmente não costumo retornar ele no corpo da resposta, justamente porque ele já vem informado nos cabeçalhos das respostas (por exemplo, usando alguma biblioteca de ajax - como Axios, ou até mesmo a Fetch API, que não é uma biblioteca mas tem tudo que é necessário -, já é possível validar o código de status de uma request), então seria um tipo de redundância. Assim, você pode deixar o corpo da resposta somente com o dado que precisar retornar. E, em casos de erro, por exemplo, eu costumo retornar apenas um objeto{message:"Mensagem descrevendo o erro"} no body, assim posso mostrar alguma informação útil para o usuário, e não preciso deixar regra de negócio (como validar o motivo do erro) no front-end, porque o próprio back-end já vai me trazer uma mensagem descrevendo o que deu errado.