Every major company I’ve been at absolutely positively does NOT MitM their own traffic. They pay security people well enough to realize what a massive hole that creates in their security posture, and makes the intercepting appliance a cess pit of regulatory toxic waste. PCI, MNPI, even HIPPA from employees visiting their health insurance site? Check, check, check! All on a silver platter for insiders and hackers.
I can tell you for a fact, having worked at them in a senior executive technical role with responsibility for security, that at least the top banks do not do this, and definitely not tech giants like Amazon. I am certain others do - but this doesn’t make it a good idea. There are a lot of bone headed things that networking hardware companies convince deep pocketed customers to do that they shouldn’t. Creating the ability to intercept traffic means none of your communications are secure within their TLS tunnels because there exists a well known and discoverable single point of failure for literally all traffic in the network.
Finally URL categorization isn’t perfect, and you end up with a leaky solution that is again, as I said, a giant cess pit of regulatory toxic waste.
Several top banks ($20b revenue +) I've contracted at internationally do MITM most of their TLS traffic to the internet, either via transparent gateway or http proxy. As do top manufacturers, insurance companies, government agencies, etc. It is probably 60/40 MITM vs not in my experience. It's a pain.
We MITM traffic at places I've been at, including government/charities. If you truly have a 'NGFW' then you can easily configure it to not MITM traffic based on categories, like healthcare.
It's pretty easy when you have your own PKI infrastructure. Which is surprisingly manageable if you have decent people running active directory services. Which is usually the single source of truth for LDAP integrations with NGFW anyway.
You can do cool things like having corporate devices have their own machine certificates that enable an always on VPN to access central resources (updates, AD, etc.) and switch to a user profile certificate as soon as a user logs into the device to get VPN/firewall access to resources that user needs.
It solves the pre-pipping problem of sending out devices to remote workers without them having to login before hand to load their profile on the same network as AD. And it's secure.
The alternative is to go cloud and in-tune everything and use Entra id, etc. which seems more popular but you lose a lot of control in my opinion and have a massive attack surface because unlike on-prem AD, the cloud is just some amorphous blob that you can't lock down using the usual things like firewalls.
I'd say, based on my experience, that if there's an 'average' big corp, they do targeted TLS proxy: on most or all of their inbound traffic to hosted services and limited category by category decryption outbound. Yes, they are absolutely concerned about legitimate regulatory and privacy concerns, but they are also concerned about data being exfiltrated, phishing attempts, identifying malicious payloads, etc.
Pretty sure that is not true, almost every major security vendors recommends Deep packet inspection of unknown traffic (which requires Decryption)
Most of the time there are white lists that exempt huge amounts of known traffic to common SaaS services, and known company resources (like Health Insurance) traffic, but if it not a known service than that traffic should absolutely been decrypted and inspected.