They may have a point. I have been involved in development of ABR (adaptive bitrate used in video clients) mechanism, and learned the following:
TCP, which is used by Netflix to download video segments, attempts to be fair by nature. I.e.: when two downloads contend, they will act similar in terms of backing off, usually leading to balanced downloads. This, however, assumes both streams have no other throttling mechanisms. Things may turn less fair when one of the downloads has a sensing and throttling mechanism on a higher level, like a netflix (or any other ABR - adaptive bitrate - based video service) client has, while other streams (your 14 year old daughter downloading Ubuntu ISOs from a fast mirro) do not.
When an ABR client senses that there is less bandwidth available, it may choose a flavour of a lower bitrate (and less quality) to prevent buffer underruns, in an attempt to guarantee smooth playback. Moving to a lower bitrate flavour, however, in TCP world, means taking less bits, meaning that a competing download gets more headroom, and senses less contention. This means that the competing TCP stream will actually quickly try to consume to newly available headroom until the netflix client again feels pressure and again has to switch down in bitrate.
In other words: ABR is not easy to do right, and you can get into situations where you are pushed further and further into a corner by other TCP streams on the same line.
A faster ISP connection increases the chance that competing TCP connections hit their own cap and don't push you in the corner further, allowing you to stay at a higher bitrate flavour.