The more detailed story is that when in recovery mode the Jetson becomes a custom USB device. Only the USB driver can change the Jetson in that state. In a normal flash over USB, when the Jetson completes the flash, it automatically reboots. The optional software is then installed over ssh, which is over any network, but it is no longer flashing. It’s simply installing via commands over ssh.
Once flashed and fully booted a Nano will provide an emulated network device on the micro-OTC USB connector if a micro-B USB cable is plugged in. This is one ethernet route for installing extra software, but it cannot flash. The actual ethernet is another network route for installing extra software, but this too is incapable of actual flash. All of these are for installing optional components (e.g., CUDA) and are actually unrelated to flash.
Some Jetsons have eMMC memory, and in addition to a partition with the operating system, those models have the equivalent of a BIOS and boot content in other partitions. Other models (e.g., Nano developer kits) do not have eMMC memory. These latter models have QSPI memory on the module, plus the SD card on the module, and the QSPI would have the equivalent of the BIOS and boot content, while the SD card would have the operating system (Linux). For either module, flash updates the equivalent of BIOS content plus boot content. For the eMMC model, flash also updates the operating system partition. For QSPI models (such as the Nano developer’s kit), many people update or prepare the SD card separately, and flash is only for QSPI (there are both prebuilt images for the SD card).
The QSPI content must be compatible with the release of the SD card content. It would be common for a Nano dev kit to arrive with a version of QSPI content too old for the most recent prebuilt SD card content, in which case you’d then want to flash the QSPI. In other cases a new SD card will “just work”, or instead of a prebuilt SD card image, JetPack/SDK Manager might be used to create a new SD card image.