JWS uses server signed claims to verify the legitimacy of the claims made. The claims themselves are plain text but can't be tampered as the signature check would fail. The plain text nature of claims is not a concern assuming SSL is used. So from a security perspective I don't see need of encrypting the claims within the application.
Then what problem is JWE really solving? Only thing I see is it would keep the claims secret even when SSL is not used. But then it is like reinventing the wheel.
JWE are not meant to be used only for transmitting claims. The first example in the RFC 7516 shows that the payload could be a message instead of a JWT. We can imagine cases where JWE are used for transmitting arbitrary messages (including binary data) from e.g. a chatbox or a contact page. In addition and depending on the encryption mode, a JWE can be computed for several recipients at once. This is perfect for a end-to-end encrypted messaging app (for example in a board internal communication).
Also, there are use cases where it is interesting (mandatory) to encrypt the data. As you noted, with JWS the data is just encoded (Base64UrlSafe) and the content is easily viewable. It may reveal sensitive data or the data structure of the issuer (especially when custom claims are sent). Retro-engineering processing is something you should also take care in the context of your application.
In most normal apps I would recommend designing so that JWEs are not required. Use of a JWE involves applications owning a private key, and the corresponding public key being registered with the authorization server. You then need a key renewal solution, and code gets more complicated. It does not scale well to many apps.
CONFIDENTIALITY REQUIREMENT
Certain information is private these days. Eg personally identifiable information (PII) such as names or emails. Avoid revealing this to internet clients in tokens. Also, claims used by APIs are best not revealed, for similar privacy reasons. This requirement sonetimes leads people to using JWEs.
SIMPLER SOLUTION
In standard web / mobile / API setups, these steps will prevent the need for JWEs:
Use response_type=code and never receive tokens on the front channel. Older high security setups (FAPI 1.0) recommended JWEs for ID tokens, but this is no longer the case in FAPI 2.0, as long as this flow is used.
Issue access tokens in a reference token format. When APIs are called, this token is introspected and a JWT response can be forwarded to APIs. This task is often done in an API gateway.
Issue ID tokens with no PII. Then, if you send one in an RP initiated logout request, no PII is revealed to the browser or server logs. Instead, web and mobile clients should get PII in HTTP requests to the user info endpoint.
CONCLUSION
JWEs are an option in your security toolbox and there may be some use cases where they make sense. The answer by Spomky Labs provides an interesting example of data protection over an insecure channel.
