The point of HTTPS is that you're guaranteed to be talking to the website you think you're talking to. Nobody can see the contents of your traffic, and nobody can modify it. You know that your message went to the right place, wasn't modified in transit, and that the response you received is the response the server sent.
But if the site uses a third-party CDN, you lose many of those benefits. In order to serve content for example.com, the CDN needs to receive your request for example.com. This means they know the contents of your request and the contents of the response. Even worse, they can send you incorrect content. Your connection uses HTTPS, but the CDN needs a copy of the service's certificate to serve requests on its behalf, so the certificate does not actually guarantee that the content came from the service.
This is similar to the power ISPs had before the proliferation of HTTPS; CDNs can know what you're looking at and even change it. And because of the economies of scale inherent to infrastructure like this, it's hard to run your own and there are few competitors to choose from.
Instead of encrypting content, services could sign it. If the service uses a CDN, the CDN could store those signed artefacts, but not the key itself. When you request data, the CDN knows what you're requesting, but it can't give you false content.
Since the CDN doesn't need to be trusted, you don't even need to use the website's CDN at all. Maybe you use a third-party CDN, or maybe your ISP operates a CDN and you use that one. Your communication with the CDN could still be encrypted, but that encryption only guarantees that you're talking to the CDN and that nobody between you and them knows the content of that communcation (as HTTPS does today), while the signature is what proves that this is the actual content of the website (which is currently not guaranteed at all).
It's possible to prevent the CDN from knowing the user's request or the server's response, while still allowing it to function as a cache: the request could be encrypted with the service's public key, and then their response could be encrypted with the request's plaintext as the decryption key. Since the encryption of the request text is deterministic, and the response can be decrypted by anyone who knows the same request plaintext, the CDN can still cache it. This way the CDN could only know what the content is if they can guess what your plaintext request was. This could be made intractable if the plaintext request includes a random identifier. For instance, an image posted in a group chat could be hosted by the CDN, but only users with access to that group chat would be able to get the image's identifier (from the service's actual servers) and so would know the request text needed to get and decrypt the image from the CDN.
This could also be used to protect copyrighted content. When a user wants to stream a movie, they would request the movie's identifier from the streaming service, then make a request to the CDN using that identifier. Only subscribers would have the identifier and therefore be able to request and decrypt the content. Of course users could always send that identifier to another user or publish it online, but that problem exists either way: if you're sending data to users, whether it's a decryption key for the content or the content itself, there is nothing stopping them from forwarding that data to someone else.