The point of this whole thing is to be able to write to "read-only" memory occasionally and be able to do it securely. That way things that aren't updated much (or that you have to be ultra careful with) can't be updated accidentally or via an exploit somewhere else in the kernel. If the memory is marked read-only most of the time then the CPU will prevent you from messing with it.
So you're supposed to start the process with one of these new functions (allowing writes), make the change, then end the process (locking the memory into read-only mode again) with another function.
This is where interrupts are dangerous. If interrupts were on then at anytime the kernel may switch what it's doing to do something else that it considers to be higher priority.
If the interrupt happens between when the work starts and the work ends then while the interrupt is running that memory is not read-only mode when code you don't control gets to run. On a very busy system you might be able to use a bug in another part of the kernel to update something that is supposed to be "read-only" because that protection is temporarily turned off.
By making it so an interrupt can't run you don't have to worry about that case.
There are a number of things in the kernel have to be run in the same mode for various reasons.
Sidenote: I've been following the LWN articles on the Linux kernel for a very long time and have learned a TON of interesting information about how all sorts of low level things work and the problems that can arise. I strongly recommend a subscription to LWN if you have any interest in this kind of stuff .