Having multiple VLANs and even routing between them on a single interface isn't a configuration problem. It is common and it does work. What I'm saying is that it can lead to performance problems. Some hardware can handle this better than other hardware.
Routing or bridging traffic back to the same physical interface increases the demand on that interface, and with a MIPS CPU, at least, this will NEVER perform as well as routing/bridging between separate physical interfaces.
The odd thing about this particular instance, is that the loss of performance is not consistent, so we cannot blame it on the hairpin configuration. The problem may still be on the MT or it may be on the TPLink. We've been through the MT and it does not appear to be at fault, so what's left?
If you want to see the performance comparison between single and multiple interfaces, try this config on any 450/493/75x/95x:
/interface ethernet set ether3 master-port=ether2
/interface bridge add
/interface bridge port
add port=ether1 bridge=bridge1
add port=ether2 bridge=bridge1
add port=ether4 bridge=bridge1
/ip firewall connection tracking set enabled=no
add interface=bridge1 address=192.168.1.1/24
add interface=ether5 address=192.168.5.1/24
With connection tracking is turned off, we should have optimal performance. From here, run the following tests using two computers and a traffic generator (or maybe just FTP). If you do, please post your results.
1) Ether2-Ether3 (Switched, does not use CPU)
You should get very close to wire speed when using the switch. The CPU will not see any traffic here.
2) Ether1-Ether2 (Bridged, two CPU interfaces)
MT/Linux bridging is pretty solid. You should still get some pretty awesome performance bridging 2 physical interfaces. Additional load on the CPU may have some consequences.
3) Ether1-Ether5 (Routed, two CPU interfaces)
Routing definitely introduces some overhead, but the 600Mhz CPU in the RB450G should be able to handle this without much loss in throughput over the bridging test.
4) Ether2-Ether4 (Bridged, one CPU interface)
Here, we're introducing a significant bottle neck. All traffic will need to pass the same physical interface (between the CPU and Ethernet controller). It wouldn't surprise me to see >60% drop in performance over test #2.
5) Ether4-Ether5 (Routed, one CPU interface)
Like test #4, all traffic is passing over the same physical CPU interface. A performance drop of >60% from #3 would not be a surprise.
Again, I would be interested in seeing your actual results. I'd run the test myself, but do not have an appropriate device sitting on my bench right now.
PS: This is not bagging on MT at all. Across the board, they are hands-down the best bang for the buck. It just never surprises me to see people try these hairpin configurations and wonder why they don't get the performance they were expecting. Knowing the limitations and capabilities of the product will result in a much better user experience.