For all others encountering this issue, there is an explanations and an easy fix.
When a tunnel drops, it's route is dropped as well, along with all affected sessions. Consequently, the outgoing traffic to the remote private network is sent out along the default route, usually through the WAN interface.
That alone is not especially bad, the next router will drop traffic to RFC 1918 private networks.
But, the FGT will establish a session for it, as there is a valid policy from LAN to WAN, destination ALL.
Now when the tunnel comes back up, there is already a current session which has to time out first before a new session through the tunnel can be established. This causes a major delay in the data flow.
There is a fix for this:
Create blackhole routes
for traffic to RFC 1918 subnets, that is, 192.168.0.0/24, 172.16.0.0/12, 10.0.0.0/8 among others. These bh routes need to have a distance of 254 (not 255!) in order to kick in when there is no better route available. The bh route will be used when the tunnel goes down and traffic will be discarded; NO session is established.
When the tunnel comes up again, a new session can be built right away, without any delay.
I've posted that 4 years ago along with a batch command file to download. Just import it (System>Advanced>batch...) to create the bh routes. This will not harm existing routes at all as they are the least attractive routes of all: https://forum.fortinet.com/FindPost/120872