You can run into issues with headerless JWTs when you can't (or don't) guarantee the order of the header. Since the header is included in the signature of JWS objects, you must reattach a header that is exactly the same, and not just equivalent.

For example, both of these decoded headers are equivalent:

{ "alg": "HS256", "typ": "JWT" }

{ "typ": "JWT", "alg": "HS256" }

Obviously, these encode to two different values. If you reattach the wrong one, signature verification will fail.

Disclaimer: I maintain a Python JOSE library and have had to answer questions related to this on more than one occasion.

Keeping the JWT format as-is is useful if you have signed (but not encrypted) tokens though; in a web browser you can use standard libraries to inspect the token and alter the UI based on a user's permissions (the final check is always the API's responsibility of course, but if there is no need to show the 'admin' link the client can do that).

There's some value in the header. Google use it to store the keyid, which is pretty useful.