Sounds like in your specific case, the advantage to fresh instances for each player or section is that you could pan each one independently. If the instrument has built in staging and reverbs, you could give each voice unique settings. You could give each player/voice their own strip, effect plugins, and AUX send settings in the Dorico mixer. You could get more control over exactly where each voice sits in your mix.
If you don’t want or need any of that, and the instrument you’ve chosen doesn’t apply fancy auto-legato effects that force the instrument to be mono-timbral (only play a single note at a time), there’s nothing wrong with sending multiple players to the same instrument/plugin/channel. Just make sure the instrument is set to supply enough ‘voices’ so nothing goes missing from the mix.
As for performance/memory…it shouldn’t make much of a difference unless you’re running very processor intensive instruments and/or you’ve a very weak computer and big score.
Overall plugin efficiency, and the eternal debate over one multitimbral instance of something like HALion/Sonic, vs lots of individual instances with only one voice/player each, etc…
It depends on the plugin, the sounds called up, host routing, and what if any effects you use to be honest. For some it makes no difference whatsoever, because all the ‘instances’ of something like HALion/Sonic 7 typically ‘share’ a common engine/memory/etc under the hood. I.E. If two different instances of Sonic are using the same violin sound, I believe they are integrated and smart enough to share the same sample cache memory pool where applicable. The HALion engine as a whole (all instances combined) tries the best it can to optimize the capabilities of your system before it sends sound out through the host.
Only way to know for sure is try things and run your own tests. In general, don’t worry about it unless you aren’t happy with the sound and want to try some different options, or the system starts choking, then you might bother to track down more resource efficient ways to set it all up.
What can matter, sometimes, depending upon your combination of plugins, and your system, is multi-threading over multiple CPU cores.
I.E. If you had 6 really processor intensive synth sounds with loads of layers each in a single HALion Sonic instance, and they all were set to use a single common stereo audio fader on the Host (Dorico) mixer, it ‘might’ bottle neck one of your cores. Spreading those same 6 synth sounds over 12 (6 stereo) audio output channels on the host mixer, OR, giving each one a unique HALion/Sonic instance (which would force new audio mixer channels) might lead to more efficient multi-threading over multiple cores for a smoother playback experience. Then again it might not make any detectable difference, or it could even make things worse.
Sometimes we push the limits of our hardware, and just have to ‘try things’ and see what happens. In short, spreading the fancy processor intensive synthy sound out over more mixing faders on the host’s mixing console could theoretically lead to better multi-threading, get rid of some bottle necks and improve system performance. Or, it might not! Sometimes the plugin does a better job at multi-threading its own loads. Sometimes the host does. So many factors can correlate or conflict over the full path of a sound from beginning to end. So ‘try things’ if you start pushing your system limits.
For HALion/Sonic/Groove Agent, Opus, Play, Kontakt, Sforzando/ARIA, and some others, multiple instances vs a single instance using multi-timbral slots over many outputs is ‘usually’ a negligible difference. Once that first instance of plugins like these is up and running, I believe all the rest share a common core engine (Each instance doesn’t need fresh copies of their entire UI and all in memory…they can share a lot of stuff from the same memory addresses), and code exists to attempt to keep all the different instances somewhat in sync, and thus optimize all those instances with the host and OS for efficient memory and thread management. What can sometimes matter is trying to stack too many ‘slots/instruments’ into a single audio fader on the host’s (Dorico in this case) mixing console.
For Plugins like these, the main advantage of going with larger multi-timbral setups from a single plugin, is that you get the ability to ‘channel bounce’ within the same plugin instance. I.E. Set up different articulations in different channels/slots. It’s usually not very resource hungry, again, just make sure the instrument is set to have a higher number of voices that can sound at the same time. Give plenty of head room if bouncing among articulations, as some of them really like to use reverb tails and such that overlap with the next note.
The theory is, the more spread out sounds are across different ‘streams’ before the host ultimately mixes to your master output, then the more flexibility the host can have in assigning things to different CPU cores in your system. It’s mostly trial and error though. No hard rules to follow on these things…
In contrast, some plugins might not share resources as more instances get opened. Each individual instance might be ‘truly sandboxed’ in its own little world. I.E. Opening two instances of something like an older Sonnivox Violin Section plugin (old VST2 code, but still sounds good) might actually require two totally unique memory pools for each instance, two independent sample memory caches, etc…even though it’s the same sound. Shouldn’t be a problem for most systems though, unless you have a pretty weak computer with less than 16gig, a really huge score (lots of instruments needing to actually play sounds at the same time), or both. In a case like this, if you run out of resources, then yeah, by all means, share that Violin Section instance with multiple players/staves, but don’t forget to set it to allow plenty of voices.
For some plugins, the more different ‘instances’ you use, it might take a little longer to ‘launch/load’ a project/score…but once it’s loaded, shouldn’t be much difference. For other plugins, it might not make any difference at all. Again, only way to know for your particular system is to try your own experiments.
For sounds that are more ‘sample based’, and don’t need to do a lot of processing in real time, it shouldn’t matter much either way. They’re essentially D2D sample players, and won’t need much in the way of processor time. You’ll just need to make sure you allow enough ‘voices’ (how many notes a plugin instance, or channels in said instance can play at the same time) for each instrument to ensure notes don’t go missing. I.E. A piano sound that uses a lot of sustain pedal…give yourself plenty of voices (32 to 64 minimum, and with most modern plugins it won’t hurt to go way higher) so dampers can work, notes can ring when sustain is stomped. For a trumpet sound, 2 to 4 should be plenty unless it’s a very fancy trumpet with layered effects like valve clatter, air noise, etc. For a violin part with occasional double stopping, go for at least 4 to 6 voices, etc. For most modern plugins, it’s better to allow more polytonal maximums than you think you’ll need (if you’re not using them, it shouldn’t rob resources. Only apply ‘lower limits’ if you run into trouble someday on a massive score that needs to play more notes at once than your system can handle, and are trying to make ‘thoughtful voice limiting compromises’ to get a project working).
These days, if you have a computer with lots of ‘slower/weaker/cooler/power efficient’ cores, I think it’s more about balancing out the load over ‘more mixer channels’ if you run into glitches. In theory that allows the host and OS to multithread better across the many mixer faders and put more cores to work before the main core out to the mains gets bogged down. Newer processors make a priority of using as little electricity as possible, not wasting energy through heat, etc. They’ll pump and throttle a good deal to conserve energy and avoid producing extra heat, so the more you can do to spread loads over as many cores as possible, in theory, that should run smoother (again, every system, project, and scenario can be unique).
At the same time, some systems might have fewer cores, but they might be quite speedy and powerful cores (that also drink more power, and make more heat). I.E. some of the older intel processors can be set to run wide open (full voltage/maximum clocks) all the time, they get and stay hot, but can take on quite a load of tasks and brute force right through heavier loads before getting bogged down.
With all that in mind, it’s hard to say there is a hard and fast rule to follow. Every system can be different. Every score can be different. So…try stuff and see what you come up with 
