I agree about the pragma.
A 'critical' section doesn't need to be in assembler, though. Something like a read / modify / write, or sending an unlock sequence to a peripheral, doesn't necessarily need to be fast but it does need to be uninterrupted.
The PIC24 architecture is particularly bad for needing specific assembly language instructions to achieve ordinary objectives. Simply reading from Flash requires 'table read' instructions to be used, which are included as built-in macros by the XC16 compiler, but the result is messy. It also means a function to, say, print a string located in RAM can't be the same as a function to print a string constant from Flash.
Writing to the register that governs the clock source is a pain too, because it requires a sequence of writes to be done not just one after the other, but actually on consecutive clock edges. This again is handled by a built-in macro, but it's a pointless restriction that doesn't really help anybody.