For me, the advantage is emotional protection when a file I know is errant/wonky and able to crash SLT or VCP. In such cases, I cannot invite that file to take down my main session activity instance of SLT or VCP.

Another advantage is that, IIRC, when SLT/VCP will crash, the file history is not on the fly-out, so if I've had the file open for HOURS or even days across suspended sessions, I can easily forget where the file is. So, I'd rather have that second instance crash rather than later regret having not refreshed my mine or jot-down notes about the file's physical location.

The thing I wish were possible would be to copy and past elements of one file/instance of VCP/SLT to another instance's file. But, I guess in the past it was hard-coded into the apps to refuse to do copying and pasting, probably to thwart license abuse in some way, say, users of virtualized instances run as trials interacting with legit instances. I, too, would rather Tim and crew be rewarded than be pirated. SLT and VCP RULE, for me at least. Despite any crashes or wonkiness occurring from time to time, I thank (the Lords of Kobol) that VCP and SLT exist. No other CAD package can satisfy me for the price point and learning curve and ease of use.

BUT, since we're allowed a certain (reasonable and generous) number of instances on one machine, I wish the installed instances can be made to cross-reference each other like device-pairing and allow the two apps to communicate, maybe hard-wired to allow only one pair, even if a third instance is invoked. Benefit: Say, on 32-bit machines or 32-bit versions of SLT/VCP, a huge file taxes the performance of the app. Instead of opening in that instance another RAM-hogging file and further bogging down that first instance of SLT/VCP, instead open a second instance, and then change the priority level in Task Manager, get out the bits needing to be copied, or measure references/distances, and then shut down the 2nd instance of the pair.