Going back to the OP’s original config… I’m not sure what ECMP to the same gateway is trying to do. If the goal trying to use recursive route with ECMP to create a “OR” on the canary address (e.g. keep WAN active if EITHER of the canary address are up), the config is not going to do that… So clarity why ether1 has multiple routes be good here. ECMP makes why more sense if there are different WANs…
Assuming CPE-like defaults, setting the same distance= on a route (either statically in /ip/route, for via default-route-distance in dhcp-client/LTE/etc). Below is why that may not be enough in all cases…
And where this gets particularly confusing is the relationship between scope/target-scope and distance. And why I generally use /tool/netwatch, with per-LAN routing tables, to disable bad route, instead of recursive routes. While RR can work with ECMP, netwatch disabling a route just more clear than all RIB/FIB/“next-hop” stuff (and icmp check in netwatch more rich with stuff like latency as a metric which is not possible recursive routes). I use /routing/rule and additional routing table called “ecmp” that does load balance, so the “main” routing table is just using failover - which allow assigning some clients to load balancing or be directed to a specific WAN using /routing/rules. See http://forum.mikrotik.com/t/routing-rule-use-cases/163178/1
Theoretically yes no mangle rules are need for ECMP with different WAN - at least for outbound connections (like LAN with HTTP traffic to two WANs). The reason why is NAT, i.e. connection tracking will keep the packets flowing to same WAN for a connection/“flow” after the initial ECMP decision.
Now…where this is NOT true is for new"/untracked inbound connections – mangle rules are needed. The inbound traffic does go to a single, specific WAN IP/port (hosting a web/other “server”, VoIP, some multiplayer WAN games), they need to go out the SAME WAN as the came in on. But ECMP (and PCC too) may result in different selection for the outbound path – which is not going to work.
So to add @mrz’s ECMP summer reading list, the PCC doc have a section on “policy routing” that applies the same to ECMP – this section of the PCC docs is also applicable to ECMP:
And I’d recommend those rules with any usage of ECMP since adding connection marks has an important benefit to the admin: /ip/firewall/connection will the show the selected WAN mark – so you can “see” the ECMP decision there by looking at the “connection mark” column in winbox/CLI/webfig.
One tip to test ECMP (or even PCC) is using a BitTorrent client (like Transmission on Mac, or whatever) to download the Ubuntu ISO image using the BT magnet links (https://ubuntu.com/download/alternative-downloads). Not saying it is the best testing methodology — but BT is pretty quick to see how load balancing is functioning since it gets pretty diverse set of IP/ports to quickly experiment with load balancing.
Apparently there is some “T2Node” thing/concept which is not described.
Each ‘Dst’ requires one or more ‘T2Node’ objects as well.
Although not sure add a description of this T2Node help folk understand any better 
. But does seem like there is a missing sentence or two in that section to fill in a few blanks.
The docs could still be clearer on ECMP (and PBR) more generally - it is spread in a few places without links to cross-reference.
Like the main “Load Balancing” page at help.mikrotik.com has a nice table of options - but no links to how one might set those up:
https://help.mikrotik.com/docs/display/ROS/Load+Balancing