It has less magic behavior.
The legacy BIOS way is basically that the BIOS will read the first sector on the first disk, check the magic bytes and if are OK match, jumps to it (executes it). All this in 16-bit real mode. For runtime services (sleep, hibernate, display backlight, etc), BIOS32/ACPI entry points are used. The services are more limited than the UEFI versions, no Secure Boot for example. For preparing/installing such a boot sequence, you need special tools, and hope, that it won't clash with anything - eventually filesystems learned not to use first few megabytes of their partition.
If you have multiple operating systems, they might not play nice with each other and each might fight for the ownership of this magic sector.
For network boot, PXE is used. Basically DHCP request, with reply containing TFTP server and image name. BIOS will then download that using tftp and execute it (still 16-bit real mode). To avoid the limits, many use iPXE - basically download more advanced loader over tftp and hand over control to it.
For UEFI, there is no magic. There is a partition formatted with FAT32 filesystem (some implementations support also other filesystem, i.e. Intel supports NTFS and Apple has also their own; but the specification makes only FAT mandatory), called ESP - it has specific GUID, though - where operating systems place files that they want the boot manager to find. Boot manager is an integral part of the firmware, so if you have multiple operating systems, you can choose which one to boot even if the operating systems (or their bootloaders) do not cooperate and do not allow booting other operating systems on your machine. For OEMs, it allows placing system tools, like diagnostics or system restore, into ESP partition too. For power users, you can place UEFI shell (if your firmware doesn't include it) here. Boot happens in protected/32-bit mode, and the runtime services are much more advanced - maybe too much, the specification has several hundred pages and many consider it bloated. A thing that might interest some, that you can instruct the firmware, how it is supposed to boot next time - you can reboot from operating system into firmware configuration without pressing magic keys at boot at the right time (`systemctl reboot --firmware-setup`). There's also standardized way to update the firmware itself ("UEFI capsule"), so there's no problem updating it, even if you are not running Windows, which used to be a problem in the past. The network boot can happen via http, including DNS resolving, where the DHCP will return URL and the firmware will fetch it. And other many quality-of-life improvements.
There have been some machines, that had their firmware thrown over the wall (mostly those cheap netbooks and tablets), where if it booted the supplied system, it was considered ready to ship. On normal, business class laptops, enthusiast desktop motherboards or server machines, I've never had a problem (except that unfortunate gen8 proliants, where HP doesn't support UEFI intentionally and limits you to legacy BIOS). The important thing to avoid having problems with UEFI is to treat is as UEFI, not as legacy BIOS.
As I wrote elsewhere on HN, Intel had a roadmap wrt UEFI, where since 2020 they wanted to go UEFI class 3 only (that means no CSM - legacy BIOS - support, UEFI only). Presentation on this should be findable on the interwebs.