Better to post this new question as a new thread.
And with export of complete
/ip configuration. It's really hard to comment particular FW rules without knowing the whole picture.
Regarding the
accept established,related,untracked rule: when a packet arrives at input interface and router determines proper chain to deal with it, it needs to check FW rules to determine action for that packet. If general rule is to drop everything (not allowed by previous rules), FW rules have to be carefully crafted.
Example: DNS request, sent by router to google DNS server ... when DNS client on RB sends out packet, firewall checks rules for chain=output. Normally there are none so initial packet is free to leave router. Connection tracking engine makes a note of new connection. Then a reply packet artives at input interface, router determines (with a help from connection tracking engine) that it's a reply packet and it should enter chain=input. If there was no rule allowing google DNS server to talk to your RB (possibly limited set of src-port), then FW would drop this packet when executing last rule (drop all). The rule we're discussing, however, allows this packet as it is part of (now) established connection. As vast majority of packets belong to established connectikns it's good to place this rule on very top of FW rule list. It is virtually impossible to construct decent FW rule list on edge firewall/router that allows outgoing connections but limits incoming connections without using this kind of rule.
And the same rule for chain=forward (for traffic that only flows through RB).
Story with "related" is similar, but for a few particular L7 protocols. FTP being prime example as it uses two distinct ports on server, one for control and one for data where data connection is initiated by FTP server and without app helper run by firewall (inspecting control flow) firewall would not allow data connection (actually already NAT even without firewall wouldn't pass it) ... and data connection is related to the already established control connection.
The same story goes with "untracked". I don't remember any protocol that can't be tracked (perhaps some of forum gurus can provide an example), but connection tracking engine can be configured not to track certain traffic.