It seems this should also be enabled when handling certain supervisor exceptions. For which exception types would it be appropriate to do so?

arm64 only enables interrupts while servicing page faults, whereas i386 does so during most trap types. Is there a general guideline to this?

At least for x86, (almost) all traps are same as the system calls. We typically have to make hardware to disable interrupts on entry because switching from usermode to proper kernel hardware state is not atomic, and interrupt handlers need to distinguish between entry from kernel mode vs. usermode to avoid doing some stuff that must not be done. Most typical problem for amd64 is SWAPGS which should be done when coming from user, but must be not when coming from kernel.

After we entered the kernel environment, and saved any additional hardware state that might be clobbered by interrupt or context switch, like %cr2 the address of the last page fault, or fs/gsbase, we typically enable interrupts when coming from userspace. For amd64 interrupts are enabled in asm code from exception.S, i386 was unified to do it in trap.c.

Normal kernel code expects that interrupts are enabled. Consider disabling interrupts as something very similar to holding a spinlock.

arm64 enables interrupts for userspace exceptions in do_el0_sync. It also needs to enable them in data_abort when not in the kernel debugger. See rS287961 and rS353920 for details.

We should enable interrupts for kernel page faults (when not in the kernel debugger as Andrew noted). There are cases where we handle supervisor-mode page faults such as copyin()/copyout() and friends, and accesses to pageable kernel memory (execve argument and pipe buffers).