It a trade off between interrupt latency and main loop latency. If you are that tight for time that you can't afford to disable interrupts for an atomic access I would suggest you need to re-architect the design or get a faster part.
The interrupt latency is the time from the event that causes the interrupt to the point where the ISR is called and you can take a meaningful action. This is a hardware characteristics, and doesn't depend on whether you're tight on time or not, whether you're busy doing something or not.
Say, in newer PIC18s, if you have an INT interrupt, you can start processing it in 200 ns (3 Tcy) since it happens (with most context already saved). Thus you can watch for an edge, and then generate the response signal in as little as 250 ns.
If you now disable the interrupts for a dozen of instruction cycles, the processing of the interrupt event may have to wait, and interrupt may be delayed, say by 750 ns. Instead of 200 ns latency, you get 950 ns latency. Now your reaction time goes from 250 ns to 1 us - 4 times worse.
Worse yet, your reaction time becomes unpredictable - it is usually 250 ns, but if the interrupt event coincides with you disabling the interrupt, it may be anywhere between 250 ns and 1 us. This may cause bad things. For example, if you used a timer interrupt to do something at regular intervals, your regular intervals become not so regular, but get sporadic jitter.
What happens if you take a faster part, say PIC32? It might have interrupt latency worse than your PIC18. See this for example: https://www.microchip.com/forums/m709091.aspx
Also, these architectures were not designed for real time, so they have things which make latency worse. For example, when an interrupt is entered, all other interrupts are disabled - so a low level ISR will disable high level interrupts upon entry and your high level interrupts will remain disabled until the low level ISR enables them back. If, in addition to this, you disable interrupts all the time manually, you make it even worse. In short, getting a faster part may actually give you worse latency.
Of course, the main doesn't have any latency, as there's no originating event.