Well… let’s forget about fasttracking first.
The whole concept of a stateful firewall is that you only take the real decisions, which require complex match conditions, when handling the initial packet of a new connection. Once a decision to let the initial packet through is made (by means of letting it through all layers of the firewall which are capable of dropping or rejecting it), the connection tracking module takes care of labeling all further packets belonging to the same connection with one of the connection states listed above, so you then can use matching to connection-state alone to handle packets belonging to all connections rather than setting up individual rules per protocol, port etc. for the mid-connection packets.
As there are many times more “mid-connection” packets than initial ones, it makes sense to place “accept established, related, or untracked” as the very first rule in the chain, so vast majority of packets ever reaches only this rule, thus saving the CPU consumption necessary to match them against any other rules. Only the initial ones (connection-state=new) and “weird” ones (connection-state=invalid) get past this rule, and are processed by the more detailed rules.
Fasttracking is an extension of this idea even further - assuming that the normal handling of packets bearing the connection-state=established or related label is to let them through anyway, why should we bother to push them through all the layers of the firewall, let’s make just the connection tracking identify them and if found to belong to an existing connection, let’s let them through. So regardless where in the rule chain a packet matches the conditions of an action=fasttrack-connection rule, the “fasttrack” bit is set in the connection context, so subsequent packets of the same connection will bypass all the firewall layers which follow after the connection tracking module.
But connection tracking itself is also quite CPU intensive - packet’s source and destination address, protocol, and port where applicable, have to be searched for in the complete list of connections, which may contain thousands of items. So for some types of traffic, it makes sense to bypass this query to the connection list - e.g. the traffic between internal subnets, or the VPN traffic between sites. For this purpose, the action=notrack in raw table exists.
So the table raw is more or less unrelated to fasttracking (because there can be no fasttracking without connection tracking), hence there is no reason to mention it in the chapter related to fasttracking.
The idea above transforms into the firewall rules created when you set the machine to factory defaults - they say “accept anything that matches any active IPsec policy” (because IPsec is one of the layers of packet processing which fasttracked packets bypass), followed by “fasttrack whatever is established or related (and, implicitly, what didn’t match the previous rule)”, and then “accept whatever is established, related or untracked” (because some small share of packets belonging to fasttracked connections is not actually fasttracked, plus to handle the untracked ones). And only after those generic rules, some more detailed ones are used to decide which traffic to let through and which not.
In most real cases you want to fasttrack the vast majority of the traffic, and only exclude from fasttracking those connections which need some specific treatment requiring that they always pass through all the layers of the firewall. So your example is illustrative but in real life a need to fasttrack only the traffic matching some detailed criteria is quite unlikely; the inverse situation (exclusion of traffic matching some detailed criteria from fasttracking) is much more frequent.
A separate case is QoS handling - if you need one, you cannot use fasttracking for most of the traffic, because fasttracked packets bypass also the queueing. And the share of highest priority traffic is usually so low that creating dedicated rules to fasttrack it would make little sense, especially since in advanced QoS scenarios, it is not unusual to decrease the priority of a connection during its existence as the amount of data it has transported increases, so that interactive communication was responsive while large downloads would give way to it.
