mount ESP to /boot. This is the preferred method when directly booting a EFISTUB kernel from UEFI.
This part of the instructions attempts to say something like this:
"If you choose EFISTUB as your boot method, then you'll should preferably do two things:
- at installation time: mount ESP to the location that will be
/boot in the Arch-to-be-installed before running the rest of the install procedure, so that the
vmlinuz-* (and optionally initramfs) files that normally end up in
/boot will automatically go to the ESP without further manual actions.
- when core Arch installation is done: configure
/etc/fstab (or any alternative mechanism of your choice) to automatically mount ESP to
/boot, so that any kernel updates will also automatically end up on the ESP.
If you choose to do something else, it will be your responsibility to do whatever is required to make the necessary files end up on the ESP."
Apparently, Arch's "recommended procedure" actually violates the UEFI standard of placing any OS-specific files under
\EFI\<OS name> within the ESP, and places the EFISTUB-equipped kernel (and optionally the initramfs file) to the root directory of the ESP instead. However, it minimizes the possibly of errors caused by the firmware ESP filesystem driver being unexpectedly case-sensitive, for example. So I can see why they've made that choice.
The chapter "Alternative mount points" then describes a number of techniques you could use if you want to use the UEFI standard paths on the ESP, and/or mount the ESP to some different location, or to keep it unmounted by default. The options are presented as a list including bind mounts and various event systems and/or scripting hooks, without explicitly describing why each solution would be applicable to a particular situation.
Basically, the Arch wiki page on EFI system partition, as it exists at the time of this writing, would be very useful to someone who already understands how UEFI and EFISTUB work, but very confusing for a beginner that doesn't necessarily have a clue what to do and how various things depend on each other. I'm not surprised about that: just listing a number of tricks applicable under a certain topic is much easier than writing a good document that introduces new concepts and dependencies between them.