I think there is something else/more going on other than just a noqueue qdisc and lack of aqm on the linux client. I suspect HE20 (an 802.11ax throughput mode) might be part of it, but I don't think this explains the green BE download ending up with all the bandwidth. I do suspect other clients on the network are contributing to that.
@ka2107: simplest thing to do is retest a few times and see if the results reproduce (if possible try this with only one client on this band and then again with a few connected).
For reference, my linux kernel 5.4 laptop with an intel 7260 wifi card (noqueue qdisc, aqm file present but I cant output from it) connected to my r7500v2 on 5 GHz, channel 36, VHT80:
Multiple clients are connected to 5GHz but only the laptop is active during this test. Durring an earlier test, all the BE download streams went to near 0 Mbps at about 40s into the test for about 5 s and then recovered. This I suspect is the result of other 5GHz wifi clients network activity.
In short, @ka2107's set up should be "running circles around mine while laughing and singing happily"
EDIT: "the earlier test"
FWIW, how AQL/ATF behaves with a "one" clinet flent test is useful to establish it's working as intended, nothing crashes, latency bugs are fixed, etc.; however, most use cases are with 6 to dozens of clients connected. I do still have wifi issues and I think they are related to how my AP behaves with multiple clients using it. I just don't know yet how to identify, demonstrate, or report it in a way that is "actionable" for a dev to fix it. I still suspect AQL/ATF contributing to that, but I also know its not all of it.
If there is still "fuel left in the tank" after the immediate bugs are sufficiently resolved, then maybe we could spend time on that - but I'm in no rush so take Aug. to ? off.