Also, I don't get how queues limit bandwidth by dropping packets. If a download is going and driving the bandwidth past the cutoff causing it to start dropping packets to limit it, wouldn't those just have to be redownloaded, which means you'll actually use more bandwidth? I'm sure I'm misunderstanding something, but it never made sense.
As @vecernik87 nicely described: TCP performs retransmissions already on protocol level, so the application does not notice it. When using TCP, receiver has to acknowledge received data to the sender. This is base mechanism for retransmissions (if sender sees a negative acknowledge, it know it needs to retransmit that packet). Sender will only transmit up to "TCP Window Size" data before getting back acknowledgements. If acknowledgements are delayed, this will lower average throughput between sender and receiver. Successful acknowledgements will increase Window size making average throughput higher. If acknowledges don't arrive in timely manner or if sender receives a negative acknowledgement, then sender will re-transmit some data, at the same time retransmissions will shrink TCP window size which in turn quite directly affect connection throughput (which is what we want to achieve by dropping packets).
UDP, on the other hand, doesn't do retransmissions so application has to deal with it. If app doesn't care about lost packets, then it's obviously fine to drop surplus packets anyway. If app does care about lost packets, then it would have to throttle down on Tx side or else the practical throughput will just drop to underground. Which servers fine those rogues apps not caring about others.
Yes, either way some more data will have to pass the connection to make up dropped packets. But probably it will do so with lower throughput which will make room for other connections to get some data as well.