The very essence of fasttracking is that most packets belonging to fasttracked connections skip a lot of stages of packet processing - mangle, filter, queues except those parented by interface queues, and IPsec traffic selector matching. So the packet arrives, gets matched against the list of all active connections maintained by the conntrack module of the firewall, and if found to match an existing connection and that connection has the fasttrack flag set, the packet goes straight to routing, bypassing all the stages listed above. NAT processing is done even for fasttracked packets of course.
What may be interesting for you is that on top of mangle rules, a routing table may be chosen also using /ip route rule. The assortment of match conditions is much smaller there: the source interface, the source prefix and the destination prefix, and a routing mark eventually previously assigned by mangle (no address ranges, no address lists, no interface lists, no matching on protocol/port, no matching on connection mark) but these rules are taken into account even for fasttracked packets. So if you want e.g. to route a whole local subnet via a Wireguard tunnel, this may be an efficient way to do that.
If actually the bulk of your traffic should go via Wireguard, you can make Wireguard the default route in routing table main and handle the rest of the traffic by another routing table, which allows you to fasttrack the Wireguard traffic instead of the rest.