In short, a direct cabling for the sync interface in ClusterXL is fine now but it didn't used to be. The following is from memory which is a bit hazy since it was so long ago.
The long answer is that a hub/switch was required on the Nokia IPSO boxes when they were using Nokia Clustering (active-active basically, not VRRP) for the "Clustering Network" between the 2 IPSO appliances. This was actually a distinct and separate interface from the Check Point state sync network. If a direct cable was used for the Nokia Clustering Network and one of the members was powered off or the cable was unplugged, it would cause an traffic interruption as the cluster state bounced and reformed with one member. Thus the use of a hub or switch to maintain link integrity (green light) on the NIC during such an event to prevent the bounce.
As for ClusterXL, Check Point introduced something called "New HA" around version NG (R50), which is more or less what we still use today. The original HA implementation was renamed "Legacy HA" and still available for a few versions after that. The "Legacy HA" code did require the use of the hub or switch for the sync network to avoid a similar traffic interruption caused by a cluster bounce if link state was lost on the sync interface. However "New HA" changed how it dealt with failures specifically on the sync interface. I'm not completely sure about this, but I think that when a cluster member detects a sync interface failure, under New HA it waits ~2.5 seconds (the ClusterXL dead timer) to decide what to do before possibly changing state. If that member is currently active and detects a sync interface failure (especially due to a dead or flapping peer) it remains active without any bouncing.
When Legacy HA would detect a sync interface failure, based on what it knew from the last CCP update from the peer, it would assume that the peer was in a "better" state and immediately go standby. If the sync failure was due to the other member dying or otherwise going away, it would take the member that just went standby ~2.5 seconds (the ClusterXL dead timer) to realize it was the only surviving member of the cluster, and return to active state (i.e. "bounce"). Needless to say if the peer member had a hardware or severe operating system problem and was constantly flapping the sync interface, this would lead to numerous cluster bounce events that were definitely noticeable.
As far as bandwidth for the sync interface, 1Gbps should really be enough. If you are having sync interface issues I doubt it is because the members are saturating a 1Gbps interface with delta state sync updates.
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com