Changing from Kernel mode to User mode (and vice versa)
Usermode to kernelmode: Wrong! ;-) Yes, interrupts are processed in kernel mode, and originally the way to enter kernel mode was by an interrupt forced somehow by software. On the DEC 2020 there was a set of UIOs (Unimplemented Instruction Opcodes), calling any of those caused a trap to the operating system. They included floating point instructions (if not in hardware) and other exotic instructions, but also the means to do operating system calls. The i?86 family has the int (interrupt) instruction, traditionally used as you say. Newer members of the family have SYSTENT to do supervisor calls more efficiently. The means of going to supervisor mode can't be privileged, but must somehow be tightly controlled by the kernel (where you enter the kernel, what arguments you pass, ...).

Kernelmode to usermode: No need for the "drop privileges" operation to be privileged. If you don't have privileges, dropping them is a no-op. But the exact mechanism is architecture dependent in extreme.

Interrupts disabled in kernel: Interrupts indicate some condition that has to be handled as soon as possible (for example, if the data arrived over the net isn't saved from the card before the next arrives, it will get overwritten). Thus interrupts are very rarely disabled. In original Unix systems (and contemporaries), there was one CPU, and the simplest way to get a critical region ("nobody mess with my data while I modify it") was just to disable interrupts. Pains were taken to keep the "interrupt disabled" stretches as short as possible because of the above. On current multi-CPU machines, disabling interrupts on one CPU does nothing much in this direction; disabling interrupts globally is extremeñy costly in inter-CPU coordination, so it is not done (or extremely rarely).