I will shed some light with you my opinion but probably there are other reasons to complete my answer.
Concerning the destination PI server, I believe the main reason for setting up the way you have described is to lower the chances of losing data when the interfaces start. If a PItoPI interface is not configured with Disconnected Startup, it will not be able to start and get the PI Point list unless it connects to the member of the PI Server of the interface batch file (/host parameter). Therefore, if both interfaces instances have the primary PI Server member selected on ICU, they won’t be able to start in case the primary PI Server is not available, even if a secondary PI Server is. In this case, there will be data loss. Nevertheless, if the /host parameter of one interface instance is a secondary PI Server, in case the primary PI Server is not available, the interface will get the PI Point list from the secondary PI Server,it will assume the role of primary and it will send the data to both members of the collective. The other instance won’t be able to send data until the primary PI Server gets available.
Concerning the source PI Server, I don’t see any major advantage unless to better distribute the load (including network, CPU, memory) between the two PI Server members of the collective.
Hope this helps you!