It's not going to help tremendously. The main thing that adjusting the priority does is assign a DEFAULT priority to all the peripheral devices on the system bus. Each individual device can override this (as can be seen with modern graphics cards). Increasing it would most likely just return you to a condition where you have more congestion, although modern machines might be fast enough you wouldn't notice without a lot of peripherals or something particularly greedy (such as an ATI X series or Nvidia 8x00).
The fact that 96khz uses a lot more bandwidth is fairly obvious, when one considers what happens to ADAT and other formats as you increase samplerate (you halve the available i/o). It's relationship to CPU load isn't as obvious and in many cases it's counter-intuitive since most people assume CPU load is directly related to having the cpu process data and not just shuffling buffers and waiting on IRQ's to release their cpu time.
Really working with lower ASIO i/o counts when working at such high samplerates is the solution to the CPU load issues. Meaning instead of trying to run 32 mono ASIO channels when working at 96khz, try running with 8. That's enough for 4 full stereo 'stems' summed in Scope.
Anyway as I said before, I can't state with authority that this is indeed his issue, but since it sounds like he was using a single ASIO channel (or pair) per 'VSTi' it really seems to me the most obvious thing.