End points are functions. From this perspective it doesn't matter what they do as long as the client is aware that this is what will happen, and is happy to deal with the output/outcomes.
So if you write the only client and you have a sequence of six operations that are called in a row, it might make sense to collapse them down into a single call that does it all.
But if you don't write the only client, then there is a good chance that such complex endpoints will make life harder for them. It would be like trying to get a paper and having to verify that you have medical insurance. Its better to have smaller concise operations to allow these other clients to pick and choose how and when.
A middle ground is to offer a small variety of common chains by opt in.
- /auth -> just the JWT token
- /auth?include=user -> JWT token + user details please
As for REST, then yes it matters a lot.
The two graces of REST are that the server doesn't have to keep connection state, and that intermediaries can cache the result to distribute to their audience to reduce overall load on the server.
JWT tokens don't fit in this model. You don't want them cached, you don't want them shared.
Other data though might be perfectly fine to cache. Perhaps not confidential user data, but if those details were public user information it would be fine.
Mixing the two types eliminates one of the benefits from a REST system. Not the end of the world, but if you are trying to get the scalability it is an anti-pattern.