The problem is that traffic shaping is only effective on one side of the pipe. The FGT can put traffic into (3) different priority queues and service them differently. For the lowest queue, it will have to drop packets to keep the bandwidth below the specified threshold. But dropped packets are forwarded from the ISP in any case (I' m talking about download traffic here) so the pipe itself will not benefit much from this.
Secondly, all BW management is done through priorities; ping as a service will have a very low priority itself, compared to ftp, http and so on. So higher RTT values with ping should not be taken as a measure of available BW. But they are indicative.
I' d set up this to clarify the situation: download a huge file (some GBs) via the 2.5 Mbps line. See it saturating the allocated BW. Now, make a second download of a huge file using the second WAN line. Here, you should be able to utitlize 7.5 Mbps BW.
If you can confirm this, you have achieved all you can with a one-sided traffic prioritization. Note that limiting BW on one link will not necessarily guarantee low latency on another one, only BW.
I think I remember there' s a KB article on traffic shaping, you might search for it for more details.
"Kernel panic: Aiee, killing interrupt handler!"