anav, I get what you are saying about making assumptions. yes that was an assumption in my part.
it was made based on my "best guess", if not correct, then we can change the solution .
second reason , is the mangle rules are needed whether it's a fail-over or load-balancing set up, in my humble opinion.
Now the fun bit: Connection Tracking. I'd love to discuss this and get to the bottom of it as I am not 100% clear myself. Reading Mikrotik Wiki regarding PCC https://wiki.mikrotik.com/wiki/Manual:PCC
(the load-balancing example) and also a old post here viewtopic.php?t=135991#p670032
both have mangle rules to ensure the traffic returns to the gateway it came. I think Connection tracking is to remember packets that belong to the same connection, when doing NAT, so it is more to do with source IP and Destination IP, knowing which IP address the return traffic should be send back to. In case of src-nat, the router send packet to 18.104.22.168 but return traffic only had dst-ip of router's public IP, it needs connection Tracking to send this traffic to one of the private IP, say 192.168.88.100, from which the packet was anticipated. So answer to your first question is yes, I think you are correct.
This is all very well, but I don't think Connection Tracking play a role in routing, in another words, to which gateway the traffic is sent to. So even Connection Tracking gives the packet correct source and destination IPs, it may ended up going out of Local network, via a different gateway.
so in case of a fail-over configuration, all traffic will be leaving the router from the primary gateway, (unless it fails) , which means incoming traffic from WAN2, WAN3, will be return to ti's source IP via WAN1. This would be a problem
OK this is the best I can do, I welcome more detailed explanations or corrections. @Sob ?
PS: I'd love to see more video tutorial on Packetflow Diagram, yes I am watching this one