Ladislav expained the topic very well, but I would like to add few words.
This not so elegant design isn't specific to R80.x at all, we had similar sporadic VPN disruptions under R77.x and the CP support explained that the standby cluster member is not supposed to send any traffic, including response packets to the VPN, at first we couldn't believe that this is being considered acceptable design, but you learn something new every day.
Such a limitation should be mentioned in VPN admin guide in capital letters and with many exclamation marks!
Any packets from the standby node addressed to any remote VPN encryption domain will trigger standby firewall to start speaking directly to the remote VPN peer and this activity is able to break existing tunnels between the remote Check Point VPN peer and the active node. Size of the impact is determined by tunnel granularity: the biggest impact is when there is single tunnel defined between the gateways and the least impact happens when there exist a SA pair for each host pair.
In the ideal world the standby node should route any traffic to remote enc domains via the active node, as it knows it is in standby state, but the existing design is different and the standby node just tries to negotiate IKE and IPSec SA-s in parallel.
As mentioned above, IPSec negotiation traffic from the standby node is detected as IPSec Replay Attack in remote CP peer and the VPN will be down for some time.