Isn't a recommendation. Is simply where the traffic originates from when doing a Signature/Patch update in that it goes out from VS0.
Same as ALL DNS requests for the VS on a VSX System originate from VS0. ( There is a thread on here about it )
Authentication Requests from ALL VS by default originate from VS0. You can select on the VSX Cluster to change that though by moving from Shared to Private.
If you then route the traffic from VS0 out via VS1 then any lookups that the box has to do will be sent out from VS0 and then back into VS1 so you then end up inspecting the lookups for the user connections on the same VS as the user connection is and then if that needs to do a lookup to allow the lookup is allowed then you can see the issue.
Isn't a recommendation that the traffic going from VS0 this simply how VSX architecturally works.
Had a customer insist on doing this whereby the traffic folded back into another VS running on the same VSX as the VS0 that originating the traffic and performance issues occurring. Performance issues disappeared once gave the VS0 Connection without going out via another VS on the same Hardware.
VS0 should not be thought of as an Internet Gateway as it should only be used for VSX Management Traffic as a Dedicated VS used JUST for Management.
So basically should have a connection to allow you to SSH/SNMP into it for troubleshooting and monitoring along with a Connection towards the Management Server if not the same Interface, along with an Interface leading to the Internet so doesn't go via another VS on the same Hardware.
From the R80.30 VSX Admin Guide
When you configure Virtual Systems to use the Application Control and URL Filtering, make sure that the VSX Gateway (VS0) can connect to the Internet. Updates are done only through this Virtual System.
You really don't need to be inspecting traffic twice on the same hardware.