Your benchmark results aren't in line with expectations, so I'd be keen to blame signal reception in your area combined with slight differences in antenna orientation and other environmental factors between your tests.
While low for LTE, I'd accept this as a common base line.
This is fishy at best, no VPN will increase your throughput (bad peering might be circumvented that way, but a crude speedtest is unlikely to show that much of a difference) - neither does adblocking (the overall results might be more snappy, by avoiding to waste bandwidth on ads, but that's not an issue for a speedtest either).
Now this can't work at all. SQM can't improve your maximum throughput, it can help to reduce your lag (and that feels a lot faster for interactive usage), but to accomplish that, it actually has to artificially reduce and cap your throughput. Its impact on raw throughput is often negligible and the benefits to keep latency at bay easily outweigh the overall throughput reduction, but an improvement of a factor of four is simply impossible this way.
Based on these aspects, I'd remove OpenWrt from the equation - do the speedtests directly on your phone, to establish a new baseline (at best OpenWrt may be able to pass everything through, but the maximum possible is still defined by the abilities of your cellular modem (phone)) and optimum reception (antenna orientation). Once you know what's possible, don't touch the phone/ modem anymore - reset your OpenWrt router to its defaults and start testing again.
- you should achieve the same values (at least very close) than running the speedtest on your phone directly, if not, there's something amiss
- adblocking is certainly useful, but it won't improve your bulk throughput - only waste less of it on ads
- if your ISP is competent, VPNs shouldn't improve your throughput either (but they might reduce it, due to the computational overhead they incur on the VPN encryption) - but with an incompetent or malicious ISP, you might get around bad peering issues,
- SQM on a variable throughput link is a different can of worms, defer this until last - yes, there are approaches to that (CAKE w/ Adaptive Bandwidth - #4 by Lynx), but they come with a hefty penalty in terms of 'wasting' significant traffic for measurement purposes. If you have monthly quotas at play, you really don't want to use this. Unless you can find a relatively reliable sweetspot of minimum guaranteed bandwidth for a static SQM configuration, adaptive SQM can only (reasonably) be used on uncapped contracts (or at least high tier ones with 'more than enough' monthly data volume).