Edited to include reference to optimize endpoint category.
We still have a lot of customers using web proxies for Internet access. Sometimes it is just a legacy, sometimes a way of controlling Internet access and other times, a network requirement (the network does not have a default gateway to the Internet). The idea of using proxies came from a time we had limited Internet bandwidth: We needed a way to minimize network usage and a local cache was the perfect idea. Things have changed since then and proxies evolved into content filters and other cool stuff. What didn't change was the fact that they keep handling network requests for their users.
One important thing, however, changed a lot. If we had static content in the web at the beginning, today we deal with dynamic and adaptive content, with data being exchanged between applications other than web browsers. So, the local cache loses most of its purpose.
Now imagine you procured a service for your company and you trust your service provider. Trust and reputation are really important here. If you trust your service provider will not tamper with your data, snoop around it nor provide your users access to inappropriate or distracting content, then the content filter loses its purposes in this scenario as well.
Sizing is another potential problem. Remember that the proxies are usually a group of computers and you have to pay for them; hardware, software, space, maintenance, operation, support, electricity... Nothing is free, right? Let's say you have just the amount of proxies you need to handle your daily requirements with a small safety margin. And you have just purchased Office 365 and are planning to deploy it within the next 90 days. Are the proxy servers able to handle the additional load? A load that is intrinsically made of dynamic content (I see my mailbox, you see yours).
If now you have better Internet services, dynamic content, a trusted service provider... why would you use a third party to intermediate all your communication with that service provider? That's my point today. It does not matter if we are talking Office 365, Dynamics, Azure or whatever other service you are using, you should be able to talk directly with that service provider without paying more than you have to.
Being a tad more technical
Whenever a device behind a proxy needs something hosted in the web, it will request the proxy to fetch the data and it will do so, based on its rules. It might be able to fulfill the request from its local cache or it will get it for the user and potentially cache the content. End of transaction.
Now, when you open your Outlook client to access your mailbox in Exchange Online, it will open some transactional sessions (request, fulfill, done) and other persistent connections. The number of persistent connections will vary from case to case, but I can say that I usually have between 20 to 30 total TCP connections for three mailboxes in my MAPI profile, with one Exchange Online Archive, two shared mailboxes a bunch of Office 365 groups and few shared calendars. Ok, I am not a good example... people at Microsoft tend not to be good examples, so let's say an average user will keep 4 persistent sessions on Outlook. 4 times the number of users you have, all of them at the same time, all the time, hogging the proxy resources.
Considering proxies are not usually designed for persistent connections and the possibility that your web proxy was not sized for the additional load Office 365 (or any other cloud service), they might become a bottleneck.
Real life example
A few months ago, I helped an FTC customer devising a remediation and deployment plan for Office 365. I remember we spoke about the impact of using web proxies with Office 365 and advised against it. Nevertheless, customer consulted their partner and decided to go with the proxy: They were told the proxy (and content filter, in their case) would be able to handle the additional load. Guess what? It didn't.
Customer came back to Microsoft asking for help because the Office 365 performance was not meeting the initial expectations. It didn't take long to isolate the problem on the content filter they were using.
I presented the findings along with the recommendation of not using proxy with Office 365. If they wanted to keep using proxy, fine. But not for Office 365, not for the service providers you trust. And at the end, after discussing the issue with network and security teams and presenting the same arguments you see here, they decided to bypass the proxy for Office 365.
At the bare minimum
All the Office 365 endpoints are categorized as “Optimize”, “Allow”, or “Default”, as you can see at https://aka.ms/o365ip. At the bare minimum, you should avoid proxy for the Optimize category.
The endpoints in the Optimize category are responsible for handling the most sensitive Office 365 network traffic and represent over 75% of the Office 365-related traffic. I mean sensitive to latency, performance and availability. And they are all hosted in our datacenters. E.g. this is where Outlook connects to get your mailbox data, capisce?
There are extensive clarification and guidance for each category at http://aka.ms/pnc. The time reading the article is a time well spent, I assure you.
If you need help clarifying the reasons why you should not use proxy between your users and Office 365, leave a comment. And if you are an FTC customer, ask one of us for help. We will get you there!