Okay, probably okay to stick to 18.06 while 19.07 goes through the RC stages, but an update is in order soon.
So what was the /etc/config/sqm for this test? And did you test over wifi or over a wired connection?
Also, please have a look at https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803/19 for how to best configure the dslreport speedtest (especially the comments about high-res bufferbloat probes and increasing the measureent duration after a free registration at dslreports)
That seems dubious from the SQM off test. My rule of thumb is that the gross shaper settings for sqm should be (for the first iteration) pretty much the maximal net-goodput rates you get from the ty[ical speedtests, and the dslreports speedtest does not seem to give you 50/10. IN your case, assuming the dslreports speedtes is reliable 35400/8500 looks like decent starting numbers for sqm, but what results do you get from ookla's speedtest (www.speedtest.net) of netflix's fast.com?
That looks about right, as does:
Why do you believe the measurements to be off? I agree that ir probably does not reflect pure propagation delay for the distance, but to me it rather indicates congestion somewhere along the line, the challenge now is to figure out where....
In the ingress, I would say you receive video streams from say netflix, amazon, apple. We should reserve the word send for data you push into the internet (and sure almost all receive connections will also cause some send traffic, but for video streaming that typically is relative low bandwidth).
Nope, typical packets are 1514 Bytes, not Kilo and not bits, jumbo frames can go up to 9KB though, but typically not outside of a carefully managed and configured local network.
Sure, as far as I can tell youtube currently oly streams at up to 60Hz....
Do you actually use egress streaming?
Fair enough, so you get your cable TV from a different supplier with its own coaxial cabling (and not some weird contraption, where there is a "cable TV" box that connects via coax cable to your TV and vie ethernet to your router)?
That might indicate some component being maxed out and limiting your game that way, might not even be on the network side.
No idea.
Okay, but video streaming, in spite of the naming, typically is not sending data at a constant rate, but it rather binges and send a batch at maximal achievable rate and fills a buffer, and when the buffer gets emptied below a "watermark" it requests the next batch, so it has some tolerance against variable network conditions and RTT variance. You game does not have that luxury unless it accepts a relative high general delay/dejitter buffer (but that leads to less zippy game reactivity which players detest).
For that you will need to either build your own shaper hierarchy with HFSC or HTB or modify the source code of the cake module. For a link that supports ~8.4Mbps egress traffic pushing 7.5 into high priority seems rather unhealthy though. (per internal IP fairness is also not going to help you much, as we two active users each only gets >= 4.2 Mbps, too little for sending 7.5 Mbps). You might want to consider getting a dedicated DSL/cable link for your gaming purposes (or a higher upload link).
The idea is that you look at the iftop output to diagnose things, not that you post videos of that 
Nope collectd is a quite helpful tool which allows to periodically sample and store different parameters from your router and the generate fancy plots. It can be quite helpful in finding issues, but let's stick to the tools you already know how to use.
So you disabled these override rules completely?
This looks odd in that the final hop does not respond, but the RTTs of most intermediate hops look reasonable to me, at least more reasonable than >=400ms.