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).
If it isn't encrypted, the only thing the client needs to know is that it's base64 encoded in order to inspect it. You'd need the secret to verify the signing and you probably shouldn't have that on the client-side!
So I still think the header is superfluous even for this use case.
edit: in fact, the client needs to know that it's base64 encoded to even read the header in the first place.
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.