Right, I said "in theory and when properly configured". It also will make a bigger difference if you have considerable bandwidth constraints. Like, for example, DSL at 768kbps uplink and are trying to play a game with 300kbps packet stream on a 15ms tick while your roomate uploads stuff via TCP to a cloud storage or something. which was the original case when I built the script.
If you have 10Gbps links you can literally put hundreds of packets ahead of your game packet and no-one will ever notice (1.2 microseconds per 1500 byte packet, so you could do nearly a thousand of those and not even induce an extra ms of delay).
But if you're gaming at say 300kbps on a 768 kbps uplink, one extra 1500 byte packet is about 15.6ms of delay, which is about equivalent to one dropped packet. Under those conditions, the realtime link freezing out the TCP packet entirely and sending the game packet on a slightly accelerated schedule to ensure you have a chance to make your control deadline is valuable.
As mentioned in other threads, if you have 3000kbps uplink or so you should be able to game with pretty much any modern qdisc and keep your game from going too far out of whack.
The tight tolerances HFSC is potentially capable of make much less difference at speeds in the 10Mbps + range which are fortunately relatively common these days. Though there are still people who have low-tier DOCSIS who might have somewhat less than that on their uplink.
For higher speeds, HFSC still allows you to have somewhat more control over the behavior of the various tiers. This is valuable if you want to control stuff somewhat more tightly, such as intentionally stalling out torrenting or you want hard real-time on your audio packets and more soft real time on video packets or whatever.