I think you are correct in that the adaptive RED code never formally made it into SFQRED. SFQRED was a brief blip in time before codel showed up... I'd talked about it in that talk as a steppingstone in hybrid fq+aqm history. (prior to that we were working with qfq + red as entirely separate, modular qdiscs). So... oops.

I think the work was interesting and valuable, and if you want to play with the ARED variant probably all you have to do is OR in the TC_ADAPTATIVE value into the flags on the red setup in sch_sfq.c

Eric added ARED support to sch_red in kernel commit: 8af2a218de38f51ea4b4fa48cac1273319ae260c

https://android.googlesource.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48cac1273319ae260c

and some ip route version later corrected "adaptive" to be the user-facing syntax. I just ran a quick, dirty and (nonsensical*) rrul test with this:

tc qdisc add dev eth0 root red limit 40000 min 30000 max 90000 avpkt 1000 burst 55 ecn adaptive bandwidth 10Mbit

tc -s qdisc show dev eth0
qdisc red 8005: root refcnt 2 limit 40000b min 30000b max 90000b ecn adaptive
 Sent 858913226 bytes 823269 pkt (dropped 4866, overlimits 123 requeues 0)
 backlog 0b 0p requeues 0
  marked 0 early 123 pdrop 4743 other 0

which "just worked" with ubuntu 13.4.

The ARED option could be enabled with GRED/SFQRED with adding the right knob to iproute2.