Well, if he has identified it as taking up a large amount of the available bandwidth, then it certainly makes sense to consider it a target for reductions. Perhaps more importantly, users tend not to care about updates like that. A user actively downloading a file from some source is probably more important than some automated process the user doesn't care about, and can be deferred until the user gets home without them noticing anything.
That said, I've been saying for a while that there needs to be some sort of bandwidth discovery protocol. My original thought process was driven by apps on mobile phones, but this seems like it would benefit for the same reasons. Wireless oeprators are always concerned about using scarce bandwidth resources so we get plans with low data caps and such. Imagine if there was a completely standardised way for an application (say an email app on a phone) to "ping" bandwidthdiscovery://mail.foo.com with some sort of priority metric. If nothing responded back, it would act normally, so the system would be completely backwards compatible. If something did respond back along the route (for example, the wireless ISP you are connected to, but it could theoretically be something local or distant. The school's DDWRT router in the OP example.) it could reject the session, or encourage a delay. That way an email app set to check every 5 minutes could occasionally get a polite rejection from the ISP asking the app to hold off since circuits are overloaded. The phone would then wait a few minutes before trying again. Eventually the phone would download new email, but at high traffic times, it might wind up going 15 minutes instead of 5, saving the network some trouble. Software updates might defer a download for days or weeks if there is a continual rejection.
My Android phone lets me set software updates and podcast downloads to only happen over wifi, under the assumption that cellular data is expensive, but wifi data is unlimited. But, if I connect to a Mifi access point connected to a cellular connection, my phone currently has no way to discover that it is actually using (limited) cellular data. With a bandwidth discovery protocol, it would get the same rejections from the ISP that it would get if it had directly connected to the cellular data itself. And, local admins could easily set up rejection rules like the OP would be interested in, while still allowing the possibility of user overrides in cases where the school IT guy really wants to manually update the school's computer systems and whatnot. Think of it as a sort of queryable QoS.
And because any intermediate system on the route can let apps know to reduce bandwidth usage, a server being slashdotted can have some queries be rejected, rather than everything being on the link local side near the user. Obviously, none of this helps the admin in the immeadiate term. But, it would seem like that's how it ought to work.