You've not checked everywhere, because MikroTik has untracked mentioned all over their Building Avanced Firewall guide.
And your CRS309 has a bare minimum default setup, but the "home-oriented" devices from MikroTik all have
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
as part of their default configuration (defconf) firewall setup.
As for why untracked is listed as one of the connection states in this rule (and the similar rule in the input chain, as well as the versions of those two rules in the IPv6 firewall defconf filter table):
In the RAW firewall table, whose rules are checked before the rules in the Filter table, you have the ability to apply action=notrack on the packet being processed. This disables connection tracking on the packet. No conntrack entry will be created, the router will not try to associate this packet with previous or future packets. This save a lot of CPU and memory resources.
Normally you use RAW rule to handle a particular high-volume traffic, that is either dropped immediately by the RAW action=drop rules (and will never arrive at the filter rules) for case like DDoS mitigation, or for traffics that you want to let pass but don't want to track with conntrack to save resources, for which you apply action=notrack. Those packets that had action=notrack applied to in the RAW table will have connection-state=untracked when arriving in the Filter tables (and other tables after RAW).
You most certainly wanted those packets to go through when you applied action=notrack, because if you needed to drop them, then you would have written RAW rules to drop them as fast as possible before that. Which means usually the filter table should let those packet go through almost immediately, without spending further resources to check other filter rules on it. That is achieved by having an action=accept rule at or near the top of the chain in the Filter table with the condition connection-state=untracked.
But there is usually already an action=accept rule near the top of the chain for connection-state=established,related. If you need a rule that accepts connection-state=untracked, then there is no reason no not combine both of them. That's why the defconf firewall has those four action=accept rules that included untracked.
But all this also means that if you never need RAW rules, or only use RAW rules with action=drop or action=accept and never with action=notrack, then you don't need to bother with connection-state=untracked in the other places of your firewall and only need connection-state=established,related in those action=accept rules.
