I strongly disagree: who is in control, how it is implemented, and the purpose of the product are all both extremely important and fundamentally different between the two use cases. An "antivirus" filter ends up implemented as a man-in-the-middle attack between software I wrote and servers I contract and control, wherein protections that were actively put in place are stripped away in order to increase the attack surface. A reverse proxy is something that I actively implemented as part of my infrastructure, and I am contracting for it and paying for it like anything else I rent.

It became "extra cool" to hate on reverse proxies recently while everyone hates CloudFlare (and to be clear: I've hated CloudFlare since before it was cool to hate on CloudFlare, and you should check my comment and submission history to verify if you don't believe ;P), but what people are essentially complaining about are "it encourages you to do something insecure", which I think is actually largely true only of CloudFlare, and you have to remember that the vast majority of developers who are using CloudFlare are doing so because they don't know much about network administration.

But like, think about it this way: Apache is also an SSL termination point. The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML": it is just a dumb encoder/decoder, and pretty exactly analogous to an SSL termination point. If you really believe in true end-to-end encryption, then having this webserver in the middle is a bad idea: you should route requests directly to database servers and ensure that at no point does any non-database computer have a decrypted copy of the information that will eventually be rendered to the user.

Another thing to think about: if you are heavily concerned that the CDN or reverse proxy service you are using has access to your traffic, realize that they are no different than using a hosted server. We don't even need to invoke "the cloud" for this one: unless I built the machine myself, I have no way of knowing that the server I am renting to run my database server on isn't running under a hypervisor that is allowing dumps of my decrypted memory. A reverse proxy is just another piece of rented infrastructure that someone else is in control of, and I don't see many people (though if you are, that's great, and then I'd be really happy ;P) insisting that everyone build their own computers and host them at their office, to make sure decrypted data never touches a computer owned and operated by someone else.

The risk profile is also just so fundamentally different, in no small part due to these differences of "who is in control and how is it implemented". Let's say that CDNetworks is failing to check SSL certificates correctly: how exactly are you going to attack that against my website? I mean, sure: if you are a state-level actor, that is going to be easy, but otherwise, that's going to be extremely rough. An "antivirus" filter that, as described in this alert, is failing to correctly check SSL certificates... well, that opens you up to attack by amateur attackers that are "close to you", such as a stalker or an ex-spouse or a corporate competitor. You can't just claim "well, if I abstract away all of the details, they look the same"... you have to look at why you care and verify that you didn't strip away anything required and relevant.