To refine this, fq_codel creates per flow fairness, which doesn't necessarily equate to per host fairness, nor does it mean that any one connection will be guaranteed max performance, just fair (or better), based on whatever flows are active in-queue.Generally, if you want something that's simple to setup and just works, look for it to support fq_codel. The benefit of fq_codel is that the algorithm does all the work and distributes bandwidth fairly while distinguishing between small(ie gaming) packets, and large(ie plex) downloads to minimize latency and bufferbloat where needed. Pretty much all you need to do is set the max limits and you don't need to worry about priorities, etc.
Largely incorrect, and a vast dumbing-down of SQM in general.Support for fq_codel has very little purpose other than when you saturate your internet pipe. It just shows up on speedtest because that is what you are doing. In every day use it has little to no impact unless you have a very slow DSL internet pipe. And remember you can over saturate your internet pipe so badly your connection will time out when you run out of buffers even using fq_codel. So the use has a very narrow margin of use. Mainly speedtest.
fq_codel's purpose is to ensure flow fairness. That's it. Only when combined with a rate limiter such as HTB does it employ the de-bloating results so well attributed to its incarnation. Independent of that, flow fairness is still being applied via 1024 FIFO queues and is still smoothing traffic flow regardless of bandwidth utilization.
As for applicable use cases, "very slow DSL" is very much the prime example, but improvements can be seen just as well across other mediums, be they cable, fiber, etc. Innate latency may be lower on those mediums, minimizing the round-trip effects of de-bloating those links, yes, but as long as the link speed delta across interfaces remains larger than a 5x or so sum (ie. a 1Gb/1Gb/s LAN egressing to a typical 300/20 cable line or a 200/200 fiber line), you'll tend to see quite a improvement with fq_codel plus a rate limiter included. If you are simply lucky enough to just "buy more bandwidth", then that's a great out, but as I've mentioned before, a good mass of end-users globally are not in that situation. In the US, particularly, the national average of download/upload is nowhere near a value that couldn't at least be moderately to significantly helped by fairness-flow queuing, on any WAN medium, irrespective of whether the link is being saturated. fq_codel, in particular, builds its effectiveness on a gradient curve. It's not saturation based.
Perhaps delve into some bufferbloat docs and educate on where the benefits really lie, and how best to apply SQM in use-cases where it's clearly warranted, which, even today, number way beyond "niche".