It's a little more complicated than that. If I click a link to an article on medium, I want 100Mbps to download it, but then I'm going to spend some time reading it, freeing bandwidth for others. There are all sorts of token bucket algorithms one can use, but like I said, a little more complicated. Identifying popular streaming services and ratelimiting them might be easier than tracking traffic usage per user per minute. And sometimes it's ok to let users download at peak speeds for more than a web page or two at a time. Maybe I download a new ubuntu ISO, which is a couple gigs and takes a while. I don't do that everyday, so the impact is minimal. It's not just that streaming video is high bandwidth, it's also very popular, and frequent, and long duration.
Ideally, we might offer users a baseline of 10Mbps all the time, and some quota of 100GB at 100Mbps regardless of source, and then people can choose what they want to download fast, but I think this would be a UX disaster.
This is a key issue. Do we want slightly more complex (per-customer fair queueing) equipment that is demonstrably fair or do we want fast and cheap kludges that are prone to abuse but trust us we swear they won't be used for evil?
In the particular case of something like Netflix, starting an HD stream then stalling and re buffering an SD stream might be a shittier user experience. How much data does Netflix download to measure bandwidth and for how long?
If I'm going to watch a show on Netflix, I want 100Mps to download it, but then I'm going to spend some time watching it, freeing bandwidth for others.
Ideally, we might offer users a baseline of 10Mbps all the time, and some quota of 100GB at 100Mbps regardless of source, and then people can choose what they want to download fast, but I think this would be a UX disaster.