[Paid Software Announcement and Discussion] Chainfire:
They have multiple because of different levels of responsibility. Exact implementation differs wildly between different devices and SoC. It is often something like this:

Primary bootloader: power on, basic peripheral initialization, verify secondary bootloader integrity and load it

Secondary bootloader: bootloader/download/fastboot mode, verify kernel and load it

All these things can be handled by a single bootloader stage, or split into many. And there's a lot more stuff that goes on.

Other related partitions that are sometimes present in the bootloader image itself (such as TrustZone) do need to be updated more regularly. Note that below this point, when I say bootloaders, I generally mean only the primary/secondary bootloaders, not the other related partitions.

On many devices, the primary and secondary bootloaders never really need to be updated. OTAs do often update them to the latest version, though.

In order of safety, here are the methods to flash these bootloader partitions:

- fastboot (or odin) - very safe

- OTA - almost as safe as above

- FlashFire - less safe

The first thing to understand is, if your primary or secondary bootloader is messed up, your device will not boot, and you cannot even get it into fastboot/download/odin mode. That is the real danger.

Even through fastboot or odin it is still possible to hard-brick during a bootloader update. The chances are incredibly low, but it is not impossible. Through OTA is almost as safe, but because more stuff is running on the system, there is a higher chance of interference. Through FlashFire is less safe.

So why is flashing through FlashFire less safe? First, FlashFire has no way of verifying if the bootloader you are flashing is compatible with your device. It could be a picture of your dog, for all it knows. This while the bootloader itself (fastboot, odin, etc) can verify the cryptographic signature and reject the update if it doesn't match. OTAs generally check device identification parameters rather than cryptographic signature, but even that is way better than no check at all.

Second, flashing through the bootloader itself or through the OTA may (not all devices do this) write the bootloaders to a backup partition, and after it verifies the flash, it actually changes the partition table to switch around the primary and backup partitions. In theory, this protects you from a bad flash in two ways: (1) if verification fails, the partition table entries aren't switched and the faulty bootloader is never loaded, and (2) if execution of the new bootloaders fails, the device could (not saying it does!) attempt to execute the backup bootloader (which after flashing and switching contains the previous bootloader version).

While many devices work along these lines, there is no standard for any of this, and thus it is nigh impossible for a generic tool like FlashFire to do this correctly. FlashFire just flashes the images to the partition, that's it. While FlashFire can of course mess up other things as well, if you mess up flashing /system, that won't hard-brick you, so it's not really risky.

It should of course be noted that the chances of anything going wrong during bootloader flash, even when using FlashFire, really aren't all that big - but it's certainly possible.

As for my personally recommended way - I'd skip on the primary/secondary bootloaders when flashing a full image, and let OTAs take care of it when they want to.