I would agree, but unfortunately it isn't that easy 
The difficulty lies in that not every setup is universal equal, this means the protocol of the isp can play a insificant role more overhead which need to be calculated with the speed, but also if the isp is doing unattended magic that is also possible, also mtu and mtu limits, and then if a split tunnel is involved this one is a complicated one sqm is not that easy to handle.
from what i know Flint 2 works better with fq_codel and less with cake, software offloading is often the cause it is not working properly, packet steering should be ok, any other concurrent qos software needs to be disabled like gl_qos/gl_eqos.
what i often do is then crank my mtu, my isp uses pppoe with a limit of 1500, though some isps allow more than what they say, more is better aslong it doesn't cause unstable latency.
when i use a tunnel connection, i need to make sure the tunnel doesn't exceed the mtu of wan, wireguard uses 60 size for ipv4, and for ipv6 80 taken from a google search this likely also has the ipv4/ipv6 already calculated, so i subtract this on the wireguard client mtu.
then i start testing, i noticed on the openwrt forums you could lower the upload very extreme and still hold alot of download speed, this needs more testing but that will give you higher speeds since upload is often not the bufferbloat issue and often the stablest of the two, so if you take those points away you can compensate for download, then decrement the speed by 10 until it looks good.
For wifi its normal its not A+, of course you can but logically it is normal to expect a bit of instability.
There are also advanced rules, but imho i never understood them i just copied them like triple isolate etcetera.
for wireguard and wan... That is still a hard one to get properly there are some scripts that can help.
