Ports require protocols, but if you do all traffic to the IP then no port or protocol needs to be specified.

Thanks for the prompt feedback! The reason I included the protocol options was because in my testing I used the "-m multiport" option to specify a range of ports. That option seems to require either tcp or udp options. I deleted that from the example for simplicity, not realizing that tcp/udp options are not required for a single port.

You may be right, but insert your rule(s) rather than append it so it it takes priority over the port based rule. Also you probably don't need the port selector so remove the "-p tcp -m tcp --dport zzzz" and use a single rule. Add your rule to /etc/clearos/firewall.d/local:

iptables -I MULTIWAN_MARK -s xx.xx.xx.xx/yy -d xx.xx.xx.xx/yy -j MULTIWAN_eth1

so the rule gets added very time the firewall restarts.

Destimation-based routing has been discussed several times. Several solutions have been proposed - for example here:
https://www.clearos.com/clearfoundation/social/community/destination-based-routing-on-multi-wan/oldest#filter-sort

I have been testing a variant of the solution proposed by houkouonchi, which involves modifying mangle rules in the MULTIWAN_MARK table to specify destination IPs. I am using ClearOS 6. This seems to work correctly - e.g. when that table directs a destination address to a specific interface, that interface is selected. This is not done within the GUI, so it could break the ClearOS multi-wan process, but so far it seems to work. This is also the same process that destination-port routing follows - creating a mangle rule in MULTIWAN_MARK to direct traffic to a specific interface.

So, I am thus confused by this comment from Legacy Disabled in that thread "Here's the crux of the problem. The routing decision is already made by the time a destination route can be added in the same manner that is done with source-based routes."

Here's my understanding of the sequencing. I am a novice with iproute2/mangle, so I may have this wrong.
weight-based routing from the LAN:
* PREROUTING chain identifies new connection
=> -A PREROUTING -i eth0 -m state --state NEW -j MULTIWAN_MARK
* nothing happens if no mangle rule exists in the MULTIWAN_MARK chain
* ip rule selects the output interface [nexthop sequence]
* POSTROUTING sets a connection mark on the connection as it exits
=> -A POSTROUTING -o eth1 -j CONNMARK --set-xmark 0x8000/0xffffffff
* subsequent packets inherit the connection mark
=> -A PREROUTING -i eth0 -m state --state RELATED,ESTABLISHED -j MULTIWAN_RESTORE
* and are routed out the same interface via an ip rule:
=> 100: from all fwmark 0x8000 lookup 100 [table 100 has a default dev]

packets coming in from a WAN interface are marked:
=> -A FORWARD -i eth1 -j CONNMARK --set-xmark 0x8000/0xffffffff
* and then processed via the same ip rule
=> 100: from all fwmark 0x8000 lookup 100 [table 100 has a default dev]

destination port routing from the LAN:
* PREROUTING chain identifies new connection
=> -A PREROUTING -i eth0 -m state --state NEW -j MULTIWAN_MARK
* MULTIWAN_MARK routes matching connections to the appropriate interface
=> -A MULTIWAN_MARK -s xx.xx.xx.xx/yy -p tcp -m tcp --dport zzzz -j MULTIWAN_eth1
=> -A MULTIWAN_eth1 -j MARK --set-xmark 0x8000/0xffffffff
* POSTROUTING sets a connection mark on the connection as it exits
=> -A POSTROUTING -o eth1 -j CONNMARK --set-xmark 0x8000/0xffffffff
* subsequent packets are handled in the same way as above

From my understanding, the MULTIWAN-MARK command can also be used to filter by destination address with the -d option. It seems like this mangle rule can filter a combination of source/destination addresses and ports. The connection mark is setup in PREROUTING, before the routing decision is made, so the ip rule will send the first packet out the correct interface. The connection is subsequently marked for additional packets.

Am I missing something? Is there some sequence that this process does not handle properly? Again, it seems like the mangle rule that handles destination ports (GUI generated)
can similarly handle destination addresses and/or source address combinations (via a script), since it starts from the PREROUTING chain. To handle both tcp and udp protocols, two mangle rules are required.
=> -A MULTIWAN_MARK -s xx.xx.xx.xx/yy -d xx.xx.xx.xx/yy -p tcp -m tcp --dport zzzz -j MULTIWAN_eth1
=> -A MULTIWAN_MARK -s xx.xx.xx.xx/yy -d xx.xx.xx.xx/yy -p udp -m udp --dport zzzz -j MULTIWAN_eth1

These rules need to be added via a separate script, not the GUI, but they seem to work properly in my testing. What's wrong with my understanding?

MultiWAN does not let you use destination IP rules, so possibly the best you can do is to use port based rules. There is this document which lists all the ports required for the Business version of Skype. You are welcome to research the non-Business version if you need it.