A couple notes:
1) codel and fq_codel are not words for the same thing. codel is a drop strategy that keeps queue lengths shorter and overall latency lower. fq_codel combines drr-style packet scheduling with a few twists to give sparser flows (think dns, voip, and gaming packets) priority in the queue over flows (big downloads) that build a queue. It uses codel to keep the resulting flows shorter. In the general case on a home router, use fq_codel not codel.
You can think of it as a drop in sfq replacement that works well at higher bandwidths, or as a RED replacement that doesn't require painful configuration, but it's better than either or both, combined.
2) fq_codel is part of the linux wireless-backports package which has been backported as far back as linux 2.6.32. It's my hope that's far enough for more distros to pick it up. It's been in the kernel since version 3.5 and continually improved since.
3) codel or fq_codel do NOT require BQL in it's most common use case, which is in a rate limited ingres/egress qos system. Where something like htb or hfsc is used to control the available bandwidth, you attach fq_codel underneath instead of the default qdisc, pfifo_fast. A ton of products are using it now in their QoS systems.
BQL support is desirable if you attach it as a raw qdisc to an ethernet device. BQL doesn't apply to wifi devices at all, and although you can attach fq_codel to the mq qdisc that most wifi devices use, work is still ongoing to make it work well with the excess buffering present in most wifi device drivers. Although openwrt has made fq_codel it's default on everything, it's a little premature to be shipping wifi AP products based on fq_codel without testing the behavior on contested links and a hard look at the device drivers involved. fq_codel works pretty well on clients with single wifi queue interfaces (think: android, or your laptop).
Lastly there are some new gear that bypass the qdisc structures in linux entirely, (octeon stuff) and I have NO data as to how well or even if fq_codel can apply there. I'm under the impression the octeons do RED in hardware, and if you can configure that, go for it... and I'd love it if fq_codel could be added to that firmware one day, too.
I'd be really happy if it showed up in microtik's products where it could apply, and wish you all well on trying it. For questions about how it works, please ask the code or ietf "aqm"l mailing list, google for 'bloat-videos', read the bufferbloat website, see the 'rrul rogues gallery'.
For status on the uptake into (for example) the cable industry, google for "active queue management algorithms for docsis 3.0".
There's far more to fix than just cable of course, and it will take a while for the industry and the ietf to settle on standards, but with the code generally available I'd hope you leap on it.