My question is why it's working without any kind of (input?) rules that allow the two routers themselves to establish and negotiate the tunnel?
Since the default firewall rules form up a stateful firewall, where the first rule in chain input of table filter says "accept (packets belonging to) established or related (connections)", and since you've probably allowed both peers to initiate the connection rather than passively respond incoming connections, both send packets to each other from the same UDP ports on which they listen (500), and hence at Mikrotik side, the initial packet from the Fortigate is treated as if it belonged to the connection initiated by the Mikrotik itself.
The same applies for ESP (the packets transporting the actual payload) if at least one LAN host at each site actively send something to at least one LAN host on the remote site. The ESP packets are sent and received by the router itself, so they are also handled by chains input
If all clients were at one site and all servers on the other one, the server site's IPsec gateway would not accept the incoming ESP. Unlike other protocols (ftp, pptp), there is no "helper" which would create a "related" connection for the ESP based on the contents of the IKE(v2) exchange. So manually configured accept rules or the mechanism described above are the only ways to make the firewall accept incoming ESP packets for the router itself.
Also I configured no IPsec ports or protocols in the filter either, were those taken care of by " ipsec-policy=in,ipsec" and "ipsec-policy=out,ipsec"?
No. Why the transport packets (ESP) get through is explained above. ipsec-policy=in,ipsec
matches all packets which came to the router via an IPsec SA, i.e. which have been decapsulated from the transport ones; ipsec-policy=out,ipsec
matches all packets whose protocol headers match any active policy so they will be matched by any of the available IPsec SAs and encapsulated into ESP. The assumption here is that you don't need firewalling between the two sites so the fact that the packets came in or are going to be sent out via an IPsec tunnel is a sufficient qualification for them to get accepted. In the forward
chain in particular, these rules accepting any IPsec payload packets are intentionally placed before the action=fasttrack-connection
one, because once a connection gets fasttracked, most of its packets bypass many layers of firewall handling and of IPsec traffic selector matching (which is the very essence of fasttracking), so we need to prevent the connections which need IPsec matching from ever getting fasttracked.