No such thing as session synchronization for different vendors. You also need to configure everything for both of these vendors, which may or may not have equal feature sets.
A sane organization will do it if the benefits outweigh the risks. An organization with sufficient risks will chose it. Most won't, because the risks (specifically, hard cash) won't be outweighed by the benefits.
But that's incidental to what was my real point, which is that if you do want a separate network, it has to be separate. Tie your two "separate" networks together with integration and you're returning single-points-of-failure back into the mix. Granted, practicality may dictate a couple of those... integrated authentication comes to mind... but you don't want the two separate networks to be all slickly and smoothly integrated for the most part.
In the context of hosting/cloud network what would probably be load balancer / reverse proxy which has the most state/sessions. And incidentally, LBs are probably the piece of dedicated network iron most ripe to be replaced with a bunch of commodity servers and some software.
Regardless, statefulness is bad of course, and less of it you have, the better you are off - we've seen this time and again: share nothing arch[1], Amdahl's law[2], locks-vs-RCU[3], memorizing tcp flows-vs-IP header hash[4,5], etc... Being able to make decision on current packet/memory access here and now, independently, without having to keep track of other flows/connections/sessions/threads beats alternative approaches every time [6].
[6] Intel's heroic effort to maintain cache coherency at all cost is a notable exception, although opinions vary wildly on whether this is actually the best thing to do, and how long they will be able to sustain it.