So whilst unlikely I would actualy bypass your switches and LAN etc, and plug straight into the TST.
If your test machine has a 10G NIC in it and is connecting at 10G you potentially have some interseting possibility for buffers in the switches to get invovled here although typically this is mroe of a problem when a large traffic flow is coming from a high speed link into a lower speed like, but consider this:
You have a very high speed connection (10G PC), connected to a moderate speed connection (1G between your switch and TST), connected to a low speed and variable half-duplex connection (The cell networks).
It does potentially create some interesting behaviour that is rather hard to diagnose, but relatively simple to bypass and rule out entirely.
The tools provided are valid for the tests they are performing, in that you are able to see that traffic between your TST and FusionHub should be good.
The two tests do differ in that the traffic via WAN Analysis is outside the VPN and may be classified differently to traffic sent when the VPN is in use, the PepVPN uses standard ports that many systems used by big carriers to identify traffic on their networks will classify as “VPN” and may get treated differently to traffic sent directly.
(I have a post here showing an example of this: UK - EE 5G Bandwidth Throttling)
This is expected, the VPN and bonding process has a certain level of overhead and there are wide number of factors that can influence this such as the variance between the different WAN links, congestion within one carriers network vs another, a high level of retries or errors on one link can also severly impact the bonding - the algoritihms can only deal with so much before ultimately they have to slow down.
This is why I did suggest running the test with the traffic sent via the VPN but with one WAN only, unless I missed it I think all your testing with the SF tunnels in place has been with both WANs enabled?
If you were testing with only a single WAN enabled do you see performance that is closer to what you would see with 1 WAN but no VPN, or do you see the traffic severly limited just by being inside the VPN, again here we are removing the packet bonding process and testing just whether the traffic being in the VPN is actually a problem (again refer to my expereince above).
I believe there is an open bug at the moment related to using domains to steer traffic and how it is impacting performance, for the purposes of testing I would simplify your setup to the extent that all traffic goes via the VPN and just connect a single device. If it is a pain to remove or disable all those rules perhaps again for the purpose of testing in a clean fashion backup your config, wipe the device and put the bare minimum config in required to enable your SF connectivity and plug a device right into the TST and test.
I know this may be repeating what you’ve already done but using a simple test setup and adding the complexity back in one piece at a time would help to narrow down the scope of what may be causing the behaviour you are seeing.