For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well.
My understanding is that you would want AQM in order to keep your bandwidth utilization closer to the actual wire speed than a simple priority queue would.
So, we've had the tools to deal with bufferbloat for a long time, it's just that this mode now just provides slightly better peak performance.
If you have a traffic shaper being fed by a deep, dumb queue, you aren't giving useful back-pressure to TCP until it's too late. You need an AQM that gives either ECN marks or packet drops soon enough that you don't build up or sustain deep queues of packets. That's the core of what bufferbloat is. The queue(s) in front of HTB in your router might not be as stupidly oversized as the queue in your cable or DSL modem, but they're still susceptible to the same problems when there's no AQM component. Some TCPs do a decent job of backing off when latency climbs, before the buffers actually fill and start causing packet drops. But AQM in the router can more directly observe and act on congestion, and works with older TCPs and non-TCP traffic.
We have been able to for years. htb+sfq has been around forever.