In Arch Linux can I mount the EFI System Partition to /boot/efi

I want to install Arch Linux but don't know if I should mount the ESP on /boot or /boot/efi

For a single-OS machine, /boot would be easiest, because:

1. The official kernel packages (linux etc.) install the kernel directly under /boot.
2. Some smaller UEFI bootloaders (e.g. systemd-boot) can boot the kernel only from the EFI system partition. (GRUB can boot from anywhere.)

Therefore, if your bootloader requires the kernel to be in the ESP, then either you must mount the ESP at /boot, or set up a script to automatically copy the kernel from /boot to wherever the ESP is mounted.

do I have to use the -p option

Look up what the -p option does, then think about whether you need it.

It doesn't make the directory special – the purpose of mkdir -p is to automatically precreate all parent directories. If you're creating /boot/efi then it'll automatically create /boot in case that's missing.

For an Arch-only installation, grawity makes a good case. If you're installing most non-Arch distributions or if you're multi-booting between Arch and anything else, though, mounting the ESP at /boot has some drawbacks, such as:

• Putting your kernels on the ESP, as would happen if you mount it at /boot, makes them available to other OSes you're booting. This could be confusing, particularly if you mount the ESP at /boot for multiple Linux distributions -- it might not be clear which distribution owns which kernel. (The Boot Loader Spec is supposed to fix this issue, but few distributions have adopted it, and it will only be effective if it's widely used.) If you're multi-booting with Windows, macOS, or anything else, putting the Linux kernels on the ESP exposes them to tampering or accidental deletion from your other OS(es). (To be sure, you can't protect Linux from damage by another OS -- the other OS could delete the Linux partition or use filesystem drivers to wreak havoc. The ESP uses FAT and is meant to be shared across OSes, though, which makes its contents more susceptible to accidental or malicious damage.)
• The ESP must be bigger to hold Linux kernels than it would need to be otherwise. If you're starting from scratch, this needn't be a big problem, since you can size it appropriately; but if you're starting with, say, an existing Windows installation, the existing ESP may be too small. In that case, you'd need to resize it (a big hassle) or use another ESP (either in addition to the current one or as a replacement for it).
• Some Linux distributions require that the filesystem that holds Linux kernels support symbolic links or other features that FAT doesn't support. Arch is OK with its kernels on FAT, though, so this isn't a problem for Arch alone.
• /boot/efi is a more common mount point for the ESP than is /boot. Although Arch's documentation and major support scripts are likely to work fine with the ESP at /boot, you might run into a more obscure support script, especially if you run something from outside the Arch ecosystem, that makes the incorrect assumption that the ESP is mounted at /boot/efi. This could lead to trouble. I don't know of any specific examples of this, but that's part of the point -- you don't know what Random Script A will do.

FWIW, I recently revised my EFI Boot Loaders for Linux page. Of the boot loaders and boot managers on that page, some are pretty much irrelevant today -- ELILO, GRUB Legacy, and rEFIt have all ceased development and been left behind in significant ways. SYSLINUX hasn't been updated in a while, either, and doesn't seem much, if any, more flexible than ELILO. That leaves GRUB 2, rEFInd, and systemd-boot (formerly known as gummiboot), with the latter two relying on the EFI stub loader that's part of Linux kernels since 3.3.0. Of these, only systemd-boot requires that kernels be stored on the ESP, and that's a major limitation. I understand the appeal of a lightweight boot manager like systemd-boot, and on an Arch-only system, mounting the ESP at /boot and using systemd-boot may make sense if you're going for the minimalist approach. If you're multi-booting, though, IMHO it makes more sense to go with GRUB 2 or rEFInd. (Disclaimer: I forked rEFInd from rEFIt, so I'm not unbiased.)