There are several reasons the ESP that may need to be accessed in a variety of circumstances:
/boot/efi/EFI/ubuntu/grubx64.efi -- This is the EFI GRUB 2 binary, which must be replaced if the GRUB package is updated.
/boot/efi/EFI/ubuntu/grub.cfg -- This is a GRUB configuration file that does very little; mainly it loads
/boot/grub/grub.cfg. This redirection is done to enable a "hook" for Secure Boot systems; without Secure Boot, the
grubx64.efi binary can be built locally and points directly at
/boot/grub/grub.cfg; but as the location of
/boot/grub/grub.cfg varies (as seen by the ESP) from one system to another, putting a
grub.cfg file on the ESP is necessary for Secure Boot, which doesn't permit
grubx64.efi to be built locally. IMHO, it would make more sense to put the main
grub.cfg and other GRUB support files on the ESP, but the developers in charge of this have opted for a more conservative approach, relative to what a BIOS-based system does. In any event, the
grub.cfg on the ESP will rarely, if ever, be updated; but that might be necessary at some point, particularly if the GRUB Debian package is updated.
/boot/efi/EFI/ubuntu/shimx64.efi -- This is the Shim binary, which is required for Secure Boot to function. Like the GRUB 2 binary, it might be updated by a Debian package update, but of the
/boot/efi/EFI/ubuntu/MokManager.efi -- This is the MokManager binary, which is a Shim support tool. Like Shim, it might be updated in a package update.
/boot/efi/EFI/ubuntu/fwupx64.efi -- This is a tool to assist in automating the update of firmware on an EFI-based computer. As with the preceding EFI binaries, it might be updated by a Debian package update.
- EFI firmware files -- Updating the firmware is likely to necessitate copying firmware files to the ESP. This could be a manual process or something that's at least partially automated using the Linux
fwupdate binary and matching
fwupx64.efi EFI binary. (I'm not 100% positive that the latter requires writing files to the ESP, though. It's pretty new and has minimal documentation at this point.)
- Other EFI-related tools -- Programs like my rEFInd boot manager and other non-standard EFI boot managers and tools might need to be installed to the ESP. The sheer number of tools that might need to be installed is significant, but most of them are exotic, so the number of systems impacted is small.
- Manual configuration file adjustments -- If you want to reconfigure a boot loader, you may need to read its configuration file on the ESP, edit it, and save the edited file back out. For that matter, simply examining the configuration requires that the ESP be mounted (although it could be a read-only mount).
- System information tools -- Tools like the Boot Info Script read configuration files on the ESP in order to generate a report on how the system is configured. The Boot Info Script probably mounts the ESP even if it's unmounted to do its work, but I'm not 100% positive of that. There may be other tools that assume the ESP is already mounted, and their functionality would be degraded if this assumption was not met.
In sum, there are quite a few reasons that the OS itself or you might want or need to read from or write to the ESP. That said, these reasons are few enough in number that a mechanism to temporarily mount the ESP and to then unmount it when done might be beneficial. Certainly a Debian package installation script could do the job, for instance, as could automated tools that modify configuration files on the ESP. AFAIK, though, changing the mount status of the ESP is not on the horizon.
Note that the ESP is mounted with fairly restrictive permissions by default. Recently (starting with 15.10 or 16.04, perhaps -- I'm not sure exactly when), mount permissions were changed so that only
root can read from
/boot/efi. Even before then, only
root could write to the ESP, although read permissions were looser. Since
root can mount partitions, there's minimal security benefit to leaving the ESP unmounted at this point, although there would be a benefit in that there'd be less risk of filesystem damage to the ESP because of a bug, power failure, etc.