The BrickPi3 firmware gets updated using the native programming/debugging protocol (Atmel SWD protocol). Since it’s handled by the SAMD hardware rather than with a bootloader, if the update fails, just try again. I think the worst case scenario is that for some reason the SAMD lock bits would get set, perhaps preventing you from writing the new firmware (which could maybe brick the BrickPi3). The most likely cause would probably be an OpenOCD failure (a SW bug), or a HW problem (maybe something else connected to the RPi stacking header that interferes with the signals when trying to update the FW). Of the thousands of times I’ve flashed/updated the firmware on the BrickPi3 SAMD (and other similar chips), including the boards getting flashed in production, I haven’t seen any evidence that any have been inadvertently locked. Also I’m not certain that there’s no way to recover from a locked chip, as I’ve never had one that was locked.
To use the Arduino Uno for comparison, the Uno is normally programmed through the USB interface. There is a USB<>UART converter that sends and receives UART to/from the AtMega328p, and a SW bootloader loads the code into the flash. If the bootloader gets corrupted somehow, the only way to recover is to connect an ISP programmer directly to the AVR to re-flash the bootloader (it’s easy, but it requires extra hardware). AVRs also have potential to be bricked (by locking them, disabling programming, etc.), but they rarely get bricked. Compared to uploading a program to the Arduino Uno, the BrickPi3 FW update is basically equivalent to using an ISP programmer with an AVR (native programming without a bootloader), so there’s minimal chance of messing something up permanently.
In my experience updating the BrickPi3 FW is very safe, with no risk of bricking the SAMD.