That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.
Okay, so now you have a third party email app that...can't send and receive email? It's not that it's hard, it's that it's basically precluded by the nature of what we're trying to achieve. I installed a third party email app so that it could talk to the network. That's what email apps do! :)
The solution for you, I think, is to just not use anything but the official gmail app while on a trusted device and network. Very sensible! But not a good option for everyone.
Also, depending on the email client and its purpose, siphoning the email to the server might as well be a valid use case. e.g., I can think of an app which manages my email by smartly figuring out which email is important and/or urgent. For the app to achieve this, having access to the email body is critical and a valid use case.
This is about peace of mind. As a user, I would appreciate the option of "lock data to device" and knowing that my data stays on my device no matter what apps I install, no matter what permissions they ask for, no matter what they fine print says, no matter how good at securing their servers they are. I'm OK to have some apps not working anymore. You only leak data once, but there are thousands of apps to choose from.
Unless I explicitly take the action to "unlock data on device", which hopefully is accompanied by messaging about the high potential risks to privacy, "are you really sure" kind of UI experience.
Make data protection a BigDeal[TM].
Ninja edit: added SMTP on the list of whitelisted servers.
If it can't fetch arbitrary images from the internet, it can't render HTML email which (even if you don't want it) is a feature many people require. Even worse, if it can't talk to Google's SMTP servers, then it can't send email, which again is a feature most people require from an email client. (I mean, it's one of the two fundamental features of an email client, so...)
But if you can do either of those, you can exfiltrate data. And since data to arbitrary third parties is fundamentally what an email client does, that's probably unavoidable. :)
(And keep in mind that when dealing with third party email clients, it's very much a one click experience to configure them to both send and receive email.)
> What desktop apps have been doing since forever [I hope!].
That's never been a technical restriction placed on desktop apps. Historically they've had no restrictions, and more recently with app store sandboxes they don't have that kind of restriction. The most restrictive sandbox mode applied to desktop apps that I know of (the OS X app store sandbox) is designed around allowing apps to talk to the network freely, but restricting their access to local resources, the exact opposite of what you want.
> Make data protection a BigDeal
I endorse this goal, but I don't think this is an avenue that leads to a solution.
If it were, you could have separate permissions for combining mail provider with network streams.