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.