Yes. As I wrote in 1985, in [1], under "Game Theoretic Aspects of Network Congestion" and "Fairness in Packet Switching Systems", about fair queuing,
We would like to protect the network from hosts that are not well-behaved. More specifically, we would like, in the presence of both well-behaved and badly-behaved hosts, to insure that well-behaved hosts receive better service than badly-behaved hosts. We have devised a means of achieving this.
The goal of fair queuing is not to improve network performance overall. The goal of fair queuing is to reward well-behaved hosts over badly-behaved hosts. If everyone is well-behaved, the queue lengths are the same, usually 1 or 0, and fair queuing does little.
There is an inherent conflict between this goal and achieving maximum data transfer rates. If you try for near 100% utilization, the problems become much worse. You can run comfortably at maybe 70%. This was an accepted tradeoff for DoD systems. DoD wants things to keep working in a crisis, even if normal operation is a bit slower.
This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and less immunity to gaming the system.
I never wrote about that much at the time, because if I had, people would have realized earlier that traffic shaping is possible, which implies that you can sell and bill for bandwidth and quality of service. We might have ended up with pay per packet.