So...
Equipments involved in testing: CCR1009-7G-1C-1S+PC and RB4011iGS+5HacQ2HnD-IN, running ROS 6.43.8, default configuration + pppoe connection + singe static dhcp lease for client + two dstnat rules
Clients: PC running Win10 1809 and Parted Magic, NAS QNAP
Software; uTorrent, Transmission, proprietary QNAP downloader, but also based on libtorrent
Internet access; 1gbps pppoe, all-gigabit wired network.
Facts;
- doesn't matter which combination is used between these routers, operation systems, torrent software - torrents speed doesn't exceed 100mpbs (linux is reporting 85-130mbps) - almost like there's a 100mbps interface ;
- direct pppoe connection from PC will obtain torrent download speeds over 900 mbps, doesn't matter by OS or software used
- any other downloads aren't suffering - speedtests, downloads over various http or remote access, all of them maxing out.
- rb4011 will display max. 26-27% cpu, ccr1009 max 95% on single core
Question: WHY?

torrent uses a random port that allows clients to connect to it, if the PC is behind nat this port is blocked and that leads to slow transfers.
maybe that's why you enabled two dstnat rules? check that the rules match the port in the pc's torrent client, check firewall rules that may be blocking that.
also try connecting one pc directly to the rb4011, that way you can check if the problem is coming from the switch.

those dstnat rules are exactly for this [static port in torrent client, not dynamic]. doesn't matter if upnp is activated, also. all tests was done with default config + pppoe + two dtsnat rules, no other rules added. doesn't matter if i keep default config rules or not [those for fasttrack]
both switches are functioning ok, tested even a pppoe connection from pc using 4011 as a bridge.
no other kind of traffic is limited, only torrent.

[later edit] downgraded routeros on 4011 to 6.43.2, upgrade it back; ccr1009 to 6.42.10 and back - all limited
even set up a tplink c1200 to calm down my paranoid ideas about isp... only to find the obvious - is working ok.
maybe is some undocumented 'feature' - like disabled routable broadcast packets, which also disabled existent wake-on-lan automation in local subnet.