This is probably a bit more than you are asking, but people have asked before, so it might be useful trivia to anyone reading…
A desktop PC has a BIOS (or UEFI in modern boards). That BIOS performs a number of clock and power rail setup stesps, plus has drivers for all of the I/O (SATA, PCI, USB, ethernet, so on). A uniform API is presented to the bootloader for a PC such that bootloaders can expect certain functions to be available and called in a certain way no matter which motherboard manufacturer and CPU manufacturer combination is encountered.
Embedded systems do not have any BIOS. All of the power rail and clock and I/O setup are done from custom software. Every single embedded system has its own customization. Typically some generic drivers exist in U-Boot, but in many cases the hardware is not generic, e.g., the PCIe controller might work with some generic chipset out of the U-Boot public software, but in many cases PCIe or other driver support might mandate the manufacturer porting their driver into U-Boot. GRUB is far simpler than booting an embedded system since it has so much less work to do (the BIOS does that work for GRUB) and so much less knowledge is required of it.
This is further complicated in Jetsons because of the earlier boot stages, e.g., CBoot, currently needing some device tree information earlier than U-Boot…and it is U-Boot which can read ext4 filesystems, and so the device tree itself must become a binary partition. Device trees in turn are custom information. I suppose it is possible build a device tree into some sort of boot CD/thumb drive if and only if all of those drivers for the CD filesystem type and USB/SATA/similar drivers are available in recovery mode, but recovery mode is much more primitive than a full BIOS.
If you were to add a full BIOS, then you could expect size, cost, and power consumption to go up dramatically (at least in comparison to size and power requirements without a real BIOS).
Recent times have motivated more secure devices (secure boot), and this just complicates it further when doing this from software. Then there is the whole bootloader redundancy, also done in software, adding to that complication. Even if you do not personally use those features, the hardware has to make this possible. Only a small amount is done in hardware (such as fuses), which makes all of that software for secure boot and redundancy yet more complicated.
The recovery mode Jetson is more or less a very simple (depending on how you look at it) interface. About all you have available is a memory controller and eMMC/RAM setup, along with a few basic abilities. The host PC creates all of those binary files which the BIOS would have replaced, and directly flashes it to the eMMC…the function of creating all of that content would be a bit overwhelming from a small embedded device.
A good reason why the host PC runs Linux is that standard Linux tools are being used to create images, and of course most operating systems have no concept of the ext4 filesystem type. All of those tools are standard and free and very high quality on Linux. You could write your own program which recreates Linux capabilities on another operating system…or you could just use Linux without all of that work.
NOTE: In JetPack4.3, once you have installed this, then over the air methods have been made to allow future updates without a full flash environment. However, you need a running system flashed from the JetPack4.3+ release at the moment of each upgrade. This is new.