Upon further thought:
This is necessary in the case of sharing data between foreground code and an ISR. However, in this particular case I think adding disable/enable interrupt code is unnecessary and just takes up extra program space.
The only reason we're saving and restoring the value at the magic number location is for the situation where that location has been mapped to a global variable not used by an ISR. This allows us to change it to 0x7777 but be able to restore it to the value the sketch expects it to be if a watchdog initiated reboot doesn't occur and the DOWN button is used to continue the sketch.
If the location is used by an ISR then we really shouldn't be restoring it at all. In the case of a timer using it, we'd probably end up setting the timer back in time. But, we have no choice because it's a fixed address and we don't know how it's being used. By restoring, we could end up messing it up in a way that the sketch doesn't behave properly when continued. For such a sketch, you would need to power off and on from flashlight mode instead of being able to safely continue by using the DOWN button.
Maybe we should change flashlight mode back to the way it currently is in the original Arduboy library:
You can't exit using a button. You just have to reboot. This would eliminate the need to save and restore the magic number value. Plus, we wouldn't need the code to detect the DOWN button and turn off the LED and screen. The code would be even smaller than it is now.
Is needing to reboot after turning on the flashlight, for it's intended purpose of actually being a flashlight, much of an inconvenience? Any objections?
As for disabling interrupts while writing the 0x7777:
Without a disable/enable, we could get an interrupt between writing the first and second byte. This might cause the first byte to be overwritten, then if the watchdog causes a reset the magic number will be incorrect.
With a disable/enable, if something would cause an interrupt between writing the first and second byte the interrupt becomes pending. As soon as we enable interrupts both bytes could be overwritten, so again if the watchdog causes a reset the magic number will be incorrect.
There may be a one or two instruction window where the watchdog could trigger and the value would be correct with enable/disable but incorrect without, but I think it's insignificant compared to the disadvantage of extra enable/disable code needed.