You skipped quite a few steps for UEFI mode. You're right that "It finds an EFI System Partition and loads \EFI\Boot\bootx64.efi" is one of them, but it is the fallback behavior (officially, it's the "removable disk" behavior) – there is a step or two that involve the motherboard's NVRAM before reaching this point.
First, as described in the UEFI Specification (PDF), the firmware provides extensive "boot" and "runtime" services (similar in principle to BIOS interrupts), among them the "Variable Services" (section 8.2) which allow the OS to save various key-value pairs in system NVRAM. (Typically it's the same flash memory aka "CMOS" that the firmware uses for its own settings, and many systems actually store all firmware settings as EFI variables.)
Usually the OS will expose the Variable Services API to user-space programs in some way, e.g. Windows provides SetFirmwareEnvironmentVariable() while Linux has a virtual filesystem at /sys/firmware/efi/efivars.
Also, as described in section 2.1 and section 3, the firmware has its own boot manager which "will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables". The firmware boot manager is basically the same F8 or F10 "boot menu" that you've probably used, but in addition to listing whole disks, now it also lists individual .efi files for operating systems.
(This feature actually predates UEFI by quite a bit – the "previously" in your quote refers to either Alpha AXP and/or Itanium IA64 EFI, both of which ran Windows; both of which existed at the same time as Boot.ini (i.e. before BCD); and both of which had firmware boot managers. I don't have links to specifications for either, though.)
The EFI "boot manager" mainly uses NVRAM variables named Boot#### (4-digit number), BootOrder and BootNext to list the installed operating systems. Whenever Windows installs its own BOOTMGR (which can be done manually using bcdboot.exe), it also uses the EFI Variable Services (through the API provided by Windows) to create a Boot0000 entry pointing at \EFI\Microsoft\Boot\Bootmgfw.efi, titled "Windows Boot Manager".
You can in fact see these entries via bcdedit /enum firmware, though they'll be heavily translated into Windows BCD-like format (as the same tool handles both EFI and BCD entries), or by running efibootmgr [-v] from within Linux or FreeBSD:
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0005,2003,0002,2001,2002
Boot0000* UEFI Onboard LAN IPv4 PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(3417eb7eda76,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
Boot0001* UEFI Onboard LAN IPv6 PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(3417eb7eda76,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0002* HDD1-1 (Samsung SSD 860) PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x100000)RC
Boot0003* Linux Boot Manager HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x80000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0004* Arch Linux LTS HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x100000)/File(\EFI\Linux\vmlinuz-linux-lts.efi)
Boot0005* EFI Shell HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x80000)/File(\shellx64.efi)
So the real steps for UEFI firmware (again described in section 3) are:
It reads EFI filesystem paths from the Boot#### variables as indicated by BootNext or BootOrder, then attempts to load and run each file as an .efi executable, in the specified order. (Boot items not listed in BootOrder are inactive.)
If none of the active Boot#### variables could be executed, it usually falls back to the "removable disk" behavior of scanning all disks for an EFI System Partition that contains \EFI\Boot\Boot[cpuarch].efi and executing that. This is also what happens if you manually select a whole disk from the firmware's boot menu.
(Practically all systems that I've seen apply this to fixed internal disks as well. This allows booting the installed OS whenever the disk is moved to another motherboard or the NVRAM data is lost for whatever reason, as well as installing an OS for EFI even if the install media can't be booted in EFI mode for some reason and therefore Variable Services are unavailable.)
(As a last resort, some firmwares (mostly those built on EDK2) will run an embedded copy of the EFI Shell, which is an interactive CLI somewhat similar to MS-DOS and lets you run an .efi file manually. Some other firmwares instead will open a file browser GUI where you can choose which .efi file to run. Others just drop to the firmware setup screen.)
This EFI boot process was heavily inspired by the one found in Alpha (which was the primary WinNT platform before x86). To some extent, NTLDR and Boot.ini in Windows NT/2000/XP imitates the Alpha AXP firmware-based boot entries, including even the use of ARC paths for the system disk.
Similarly, Windows XP was also available for EFI on the Itanium IA64 where it relied completely on the EFI boot manager (as far as I know, it did not have its own boot menu), so "These parameters were previously in..." most likely refers to XP's use of native EFI boot manager features alongside the x86 version that used Boot.ini.
(So I suspect that the current Windows Boot Manager and its BCD was created because Microsoft kept finding the AXP- and EFI-provided interfaces inadequate, but it still mimics EFI-style boot to some extent, e.g. even BIOS installations now have a dedicated "system partition" and no longer place BOOTMGR directly on C:\.)
Perhaps because of the latter, the bcdedit tool manages both kinds of boot entries – both EFI firmware as well as Windows BCD – through a unified interface. For example, by default bcdedit will list the Windows BCD entries used by BOOTMGR, but if you specify the /enum firmware option, then it will list EFI NVRAM entries used by the firmware boot menu (although in a format very different from the real thing).
