I wanted to add this today after yesterday's testing. If it's too low you will indeed end up with stuttery mess - this will include if you're using a VPN connection on any client of course since there's an added length to travel to the server before the sites you want. "Accommodating for the worst connection". Those that aren't on a VPN on my end do benefit for metro on upload (even on wifi), however as I do use a VPN on some clients, I've bumped it to 25ms and will probably raise it a smidge higher still.In my super quick testing, reducing rtt below the time to the first hop (plus a little overhead) resulted in reduced throughput. It would seem based on this, that rtt functions something like an fine-tune setting.
if latency above rtt > throttle harder
I suspect that changing the value is only really useful in very specific cases to fully optimize and target a specific use (data center/high latency satellite), and won't have any real value for typical conditions.
You can also specify measurement method. Rather than "8000", you can use "8 ms".
The setting definitely has a positive effect on performance if reducing latency is your goal and you can afford to lose some of your throughput for a very visible benefit, but I agree that there should be a limit and you shouldn't go so low. 100ms is the default, I just think that could be a bit tighter. Some people might have really shaky connections and should avoid this at all costs