The proper solution for data plans is not to avoid features that are harmful in their presence entirely, but rather for the OS to be aware of when it's connected via a metered/capped connection, and behave differently. Just like how Android devices can detect when they're connected to "open" wi-fi hotspots and auto-wrap their connection in a Google VPN.
Just because you have a logical reason to not want to serve updates, should not prevent IT admins from getting a good default experience when they have 1000 machines on a LAN that all want to update.
> but rather for the OS to be aware of when it's connected via a metered/capped connection, and behave differently.
Pretty much all internet connections are metered/capped, though prior to recent FCC transparency rules the caps on residential fixed broadband were often undisclosed or affirmatively misrepresented under false "unlimited" labels.
Making the OS appropriately sensitive to the costs incurred by each network-involved transaction relating to updates and the system owner's preferences regarding balancing those costs against the value they provide in update experience is abstractly ideal but decidedly difficult.
As i was saying above, the majority use-case of update sharing is sharing updates over a LAN to other computers in the same office.
Note that, even in that case, the connection to the outside world might still be metered/capped—but the connection to LAN peers obviously isn't. That means that "does this traffic cost anything" is an evaluation the OS would have to make per socket (or requested socket from a higher-level library, like Windows' BITS), rather than per interface.
Just because you have a logical reason to not want to serve updates, should not prevent IT admins from getting a good default experience when they have 1000 machines on a LAN that all want to update.