Ultimately you’re trusting the site owner to be responsible and almost never have the ability to audit them. Using CloudFlare is another trust point, just like using shared hosting. If you don’t complain about using AWS, Digital Ocean, etc. in the same way that’s just saying you need to think about the threat model more.

I don't understand why Cloudflare comes for special criticism here. Anyone whose TLS connection terminates in a cloud hosting provider has the same potential concern as they would with Cloudflare. And it's just as easy to tell: just look up the DNS settings.

Most end users as of very recently never even knew if access to a website was ever secure or not. The huge rise in TLS deployment (in part through services like Let's Encrypt and, ironically, Cloudflare), and browser UX mechanisms are only thing that has really increased awareness of these problems for non-technical audiences to any degree, I'd say. But in the large, it matters less than you think because even if the connection is "authentic", TLS has never specified any level of rigor or security on the actual backend service itself. What does it matter if a user knows the connection is "authentic" if the service they're using just sells access to all their data anyway or is a pile of shitware that will get hacked? Which they can't know in any way, as they are unable to audit the service itself. As deployment of TLS continues, these are becoming the real problems, as opposed to WiFi-style edge hijacking attacks at your coffee shop.

Alternatively, other 3rd parties on the network could do this stuff like Cloudflare or your hosting provider, but generally a lot of the issues you see here that impact people day-to-day (fraud, identity theft, etc) are all "first party" issues as opposed to third party ones. Or at least it seems that way to me. Put another way: If an average computer user asked me to recommend a service, I don't evaluate its security (a factor in the recommendation) based on whether they use a CDN. I evaluate it based on a host of other technical/social factors -- business model, auditing availability, track record, outward security posture, user support, what's actually at stake vs cost, etc -- which are largely a result of relevant domain experience on my behalf, and even then, only approximate and fuzzy by nature. And in extreme cases -- yes, even Cloudflare might be unacceptable, but you can't put the cart before the horse.

TLS is, and only ever has been, a transit security mechanism, never one that actually established a "contract" -- firmly a social/political idea, not a technical one -- between two parties about the information in-transit. I mean, we might like it to be that, but it's provably not. The threat model of the open internet is really incredibly opaque and complex for most developers to understand, much less any end user, because of things like this. It's probably best not to mislead end users about things like caching technology/caching services (already highly complex technical topics), because we want simpler models to think about.

Unless a site is hosted on the site owner's physical hardware, some third party is being trusted this way. A shared hosting provider could dump the server traffic, a VM provider could extract TLS session keys from the guest's memory.

You can't do anything digitally without trusting thousands of vendors along the way.