Currently I have ‘in-interface-list=WAN’ on my dst-nat rules.
Is there any advantage to changing this to “dst-address=cloud_url”? (besides deals with hairpin nat effectively).
Where cloud_ulr is a firewall address list with name of my ddns MT cloud service (or dyndns service provider URL for that matter)?
The only advantage I can see is the one you’ve already stated - if you use dst-address-list=myfqdn in the rule, it works for packets coming in via any interface. The address list looks like list=myfqdn address=your.dns.name. For the same purpose, you can also use dst-address-type=local dst-address=xxx.0.0.0/, where xxx is the first byte of your public IP if it doesn’t change and differs from 10, 172 and 192.
Well fancy, if you mean myfqdn is equivalent to the address of my WAN IP as reported by a dyndns type provision, then yes LOL. as for type local, easier to type =!LANIPofSUBNET
In any case, the reason I really asked is that in another thread, in-interface-list=WAN for a plain jane dst-nat rule (no hairpin required), an OP is reporting that it is not working at all for EXTERNAL clients. I cannot figure out any good reason to explain this. 
The person ended up using the dyndns variant above successfully.
If you need port forwarding only from outside, then using in-interface or in-interface-list is the simplest solution, because it will take everything, no matter what the destination address is. Even if some hacker in ISP’s network would be sending packets with random destination addresses to your router, this rule would still match and would forward them to target device. The only way how it can not work is when you use wrong interface. For example, if you’d have PPPoE, but instead of using that, you’d use parent ethernet interface.
The reasons against in-interface(-list) and for dst-address(-list) are: