I see problems with them as well. There's the security risk that the products might have vulnerabilities that expose end users. Secondly, they may cause other problems that are not security problems. For instance, I have experience of a solution where HTTPS proxy mangles AJAX stuff that goes over HTTPS. This will cause very weird problems that are hard to debug.

Here the problem is not that the proxy would be trying to insert advertisements to the content. Just changing IP addresses within AJAX content may break functionality in nasty ways. For instance, so that things work with some browser and not another one, or reuiqre a particular engine setting in MSIE11, or some such. There is no problem in the service itself, but the service gets the blame because people can't think that a Cisco product in between might be the cause.

Of course there are security implications with central services like an enterprise-grade proxy. And anyone using such a solution must do the best to keep it secure. It is all a question of probability and of costs. I bet, most vendors of such solutions will do their best to protect them and their customers. So a network security solution that might have a exploitable hole in a period of time is better than none.

I've been working my entire career for large companies. I've experienced many solutions and I cannot remember one technical problem that was caused by network security, other than "InsertYourSocialNetworkOrBinary was denied by SecurityRuleXYZ". At several companies I had to sign a paper that informed me about the security implications and my duties when using the companie's Internet/network access.

I have also worked for larger companies, mostly, and within them I have actually experienced many technical problems caused by network security solutions.

HTTPS man-in-the-middle proxying is one particular scourge that causes weird things - the problem reports being of the kind that in a completely legitimate and intended use case, "Chrome works, MSIE does not".