A different slant on the usefulness of changing interrupt priorities:
The interrupts do not have to be simulataneous for the lowest priority to lose out. All it needs is for there to be 2 or more interrupts pending on exit from an ISR since this is when the priorities are evaluated (ie there isn't a first in first out queue - its a case of the core evaluating the highest priority when the I flag is clear).
Say you have 3 interrupts enabled and call then INT1, INT2, INT3 and lets assume INT1 has the highest and INT3 the lowest priority. Now if INT1 and INT2 keep hogging the processor bandwidth, momentarily chewing up 100% (due to poor design or whatever), then poor old INT3 might have to wait for them to both to be idle. By prioritising INT3 at the highest level it will be the first ISR handled on completion of the current ISR, whichever that is. Obviously the more interrupts in a system the longer it could take to the lowest priority if the higher priorities keep overlapping.
Therefore if you (a) keep your ISRs to a minimal execution time, and (b) set an appropriate highest priority, you can have deterministic max latency to the specific highest priority interrupt.
Re-enabling interrupts in an ISR is not for the feint hearted and I would want to see a very good justification for it if I were doing a design review..
Cheers
Colin