This question can go arbitrarily deep into bootstrap firmware and designs, and into operating system design, and inherently touches on software licensing.
I'm going to intentionally gloss over some of the details in the following, as this text input box isn't big enough for that, nor to include a computing system architecture course.
I'll also infer that you're probably familiar with Windows and BIOS. (Other operating systems don't have the limits you're apparently accustomed to.) My knowledge of the Windows bootstrap sequence is also dated, so I won't discuss particular details of that here. (And some of what I do mention here may well be stale.)
Windows expects rather little from its BIOS (and BIOS delivers on that), and the Windows installation sets up the bootstrap environment; what drivers and such are loaded. That's an old and simple design and can also make for a fast bootstrap as the operating system bootstrap doesn't have to scan for arbitrary hardware to figure out what drivers and extensions are needed. This design is also fairly good at keeping the installed copies of Windows tied to specific boxes for licensing reasons, but it's obviously not particularly flexible for end users. (Windows can detect and allow some number of changes and allow bootstraps as part of its licensing; it's not fixed at installation time.)
BIOS is probably most charitably referred to as simplistic.
EFI is years newer than and rather more capable than BIOS, and (in its full implementation) offers a command-level shell, and contains "simple" boot-time drivers for accessing various bootable devices. EFI is most charitably called a cryptic environment, but it's quite flexible and (as the E in its EFI name implies) extensible.
EFI also means the OS can use the bootstrap drivers, while the OS is getting going, too. (Though the transition from its bootstrap mode to its configuration and capabilities when the OS is running is, well, decidedly odd and weird. But that's fodder for another day.) EFI contains the aforementioned drivers, the ability to access a GPT partitioned disk device, and a FAT file system, which means it can access the target disk and read data off of it. Without an operating system around. Which can (and usually does) include reading in parts of the OS bootstrap, console or hardware diagnostics, or, well, whatever else the folks working with EFI want or need.
OS X very effectively hides EFI from us end-users. Which, having worked with EFI, is a Good Thing. But I digress.
OS X and various other operating systems can load the necessary drivers and extensions dynamically; during bootstrap. (In the case of OS X, the bootstrap will prefer to boot from the kernel cache when/if that can be located, but will load without it. This caching for boot speed. It's also why you'll see the occasional discussion around invalidating the boot cache, either when hunting a bug, or as happens after a software upgrade.)
Because you can only purchase the hardware from Apple, OS X isn't tied to a specific Apple hardware installation (single box) nor to specific boot devices, and - as is the case with other operating systems - can boot from most any media that EFI can recognize and then access and load the OS X bootstrap from. (This short of performing certain acts I won't further discuss here.) (Search for DSMOS or DSMOSX for some related details.)
SMC is a low-level bit that "controls" certain key portions of the hardware. It's arguably not particularly related to the bootstrap. Well, other than that SMC can and does deal with the state of certain low-level parts of the hardware until the OS is ready to deal with the task. SMC also deals with licensing.
For (far) more (technical) bootstrap details for OS X, see the Apple Kernel Programming Guide documentation The Early Boot Process.