The bootloader is read-only. What the bootloader loads isn't. If the thing you're trying to boot into is faulty, it doesn't matter because you can just replace the thing the bootloader is trying to load.
If the bootloader itself was faulty, the device would be bricked.
When the bootloader is not read-only, you can upload another bootloader.
This is great in a different way because custom bootloaders allow for more flexibility.
For example, you may want to keep two copies of your firmware on the chip: One that you're uploading, and one you can fall back to if the most recent one has problems. This protects you against failure during firmware upload or post-deployment failure, because you only overwrite one of the two. So if the device switches off while flashing it, and you boot back up, a custom bootloader can just default to the older copy.
But... what if you update the bootloader and it fails?
Then you can't use the bootloader to upload new firmware. Bricked.
To unbrick a bootloader you need to overwrite the bootloader using alternative methods that don't involve the bootloader, which usually involves attaching wires to the print. This is highly inconvenient in a production setting: Maybe your hardware is encased, embedded in a bigger thing, or located on a pole on a mountain top in a different country.
So a read-only bootloader is a safe choice, and you can make other workarounds wrt. flexibility.
You can have several bootloader stages, and in fact that's how the RP2040 works [1]!
Stage 1 bootloader is the one in ROM and it normally just reads stage 2 from the flash chip. Stage 2 then initialises the flash properly, and you can have further stages like [2] to implement the trial-rollback procedure.
Stage 1 is a safety net, even if the trial-rollback procedure goes terribly wrong the device can still be unbricked over USB.
I used to work on a product where we did exactly that, and the devices literally ran on mountain tops. Our development and testing process was very rigorous and would be unrecognizable to most developers today, however. We certainly weren't shipping new code to those devices after every sprint.
If you anticipate the need to update the bootloader, you would use a multistage bootloader approach where the first is never altered (as the bootloader should never be altered) and its main function is to select which updatable second stage bootloader to load from multiple options (multiple so that even if one is interrupted mid-update by the application, there is a valid fallback).
My gut says if you're worried about this in the bootloader, it might be doing too much.
Particularly neat approach to both reducing the attack surface of the bootloader and improving the reliability of the actual OTA update process is to have only the bootloader flash the active application/second-stage flash partition. The idea is that the normal application code somehow acquires the new version, verifies it and writes it into separate flash partition and then reboots, bootloader sees that record and, does minimal check for correctness and flashes that to right location. That way the bootloader does not have to know anything about how to get the new firmware image and does not process any untrusted input.
When I actually have these conversations with security guys, it's because they've either missed their window on contributing to part selection (in one case because that team hadn't been hired yet!) or no one consulted them in the first place. In both cases the solution is to write some guidelines and get the EEs to use them during part selection in the future.
If the bootloader itself was faulty, the device would be bricked.