It's the whole point - they're signed, not encrypted.

You should use opaque tokens instead if you don't want the frontend or other services that have access to the token to read it.

In many cases, the front end doesn't need to read the JWT, just pass it on to some API.

An encrypted JWT is still convenient as it can be decrypted and deserialized into a common data structure using existing libraries.

One benefit of JWT as specced is that those APIs you pass it on to don't need to share an encryption key, which makes rolling the key without causing downtime impractical. With OIDC, for example, frequent key rotation helps you create a better security posture.

The benefit of signing versus encryption is many services are able to verify the authenticity without needing a shared secret. That includes untrusted services, which is frequently the case with OAuth 2.

You can encrypt a JWT token, but at that point it's not semantically a JWT anymore. It can be any JSON at all and doesn't need to match the JWT structure. The first and last parts of a JWT are a signing algorithm and signature, respectively.

I, for one, enjoy not needing to coordinate an encryption key between my service and my IdP.

I also enjoy not worrying about how the next field I add to my JWT can be exploited after a base64 decode :-)

How else could frontend read them? If you don't need this then regular cookies are better.

It's the other way round - the front-end shouldn't need to read JWTs, just pass them on.

if your frontend is interrogating the jwt you're doing it wrong

Isn't it pretty common to read the expiration so you know when to refresh tokens?

It is, among other things like username or user e-mail address.

This is also, together with backend scalability, a major selling point for JWTs. Otherwise one might just as well use regular session ids in cookies.