/boot/efi is a filesystem on the system disk, typically a FAT32 filesystem.
The terminology here is far from uniform: your first book takes the view that the part of BIOS that handles the selecting the disk to boot from and loading the first stuff from the disk is the bootloader... or at least the primary one.
In BIOS firmware, the primary bootloader embedded in the firmware has very limited capabilities: it essentially just reads one block from the beginning of a disk and then executes it.
In UEFI firmware, the primary bootloader is way more capable: it understands FAT32 filesystems (and optionally may understand other filesystem types also), and so it can load a specified file from a specified filesystem, or from a standard fallback file from any supported filesystem; for 64-bit x86 systems, the standard fallback file pathname is
Your other book glosses over the BIOS component of the boot process, and focuses more on the second part of the boot process: the on-disk bootloader, which can be (but does not have to be) specific to the operating system being booted. This could be called a secondary bootloader, if you need to talk about both it and the in-firmware primary bootloader. But if you are not talking about the internals of the system firmware, it is common to refer to the on-disk secondary bootloader as just "bootloader" also.
For an alternative terminology, let me describe how HP-UX did it on PA-RISC hardware:
- the firmware was known as PDC.
- the PDC firmware included an in-ROM bootloader routine called
IPL, or Initial Program Loader. As the name implies, its job was to just load and execute a single program.
- the first program loaded from disk by the IPL routine was called
ISL, or Initial System Loader. Its job was to load the actual operating system kernel. It actually first loaded yet another module,
HPUX which dealt with loading the actual HP-UX kernel.
Since firmware can be hard to update, splitting the bootloader into multiple components like that makes it easier to change the structure of the operating system kernel if required by development innovations: only the relatively small (secondary) bootloader (ISL) absolutely needs to conform to the firmware API requirements. Any subsequent components can be reprogrammed to do things completely differently if necessary.