One remark on that:
now clients can't deduce what they can do or if their token still active
The safest way to store the JWT is probably in a httponly (to prevent XSS) secure cookie (+ take measures against XSRF). If you do that, client-side code can't directly check the JWT anyway.
As for your initial question, I guess it can help give more control over revocation / session expiration. If you hand out the JWT to the end user, you are powerless until "exp" is reached (and this parameter has been decided by the issuer, which might not align with your own policies). With the opaque identifier, you keep control and can revocate access anytime. In a way, you keep old fashion session management while still leveraging JWT for delegated authentication.
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
Unlike sessions - which can be invalidated by the server whenever it feels like it - individual
stateless JWT tokens cannot be invalidated. By design, they will be
valid until they expire, no matter what happens.
http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
For a stateful service, you hand out a new short-lived, single-use
token for each service - which is then exchanged on the service
itself, for a session on that specific service. You never use the
token itself as the session.