Well, guess what all the recent QEMU stuff is good for - it allowed me to understand a lot better how these cameras work, and how to diagnose them if anything goes wrong. I'd say the risk is very low, and very unlikely to cause unrecoverable damage; however, it
is at least theoretically possible to erase the bootloader by jumping to the wrong program counter in the ROM. The risk is probably the same with any recent builds.
There is a lot of room for improvement, but all that requires low-level reverse engineering,
feedback from knowledgeable users, and I'd even try to intentionally brick my own cameras to test the effectiveness of the safeguards (I already tried with simple scenarios I knew how to recover from). I have a couple of ideas to try in QEMU, such as writing random noise into Canon's data structures that are going to be written into ROM, and then preventing the reflashing process that takes place at shutdown. On 5D3, this is done to some extent - for example, Canon settings are not saved if you had to take the battery out or if you got some assertion or ERR70.
One idea I did not explore yet: a way to prevent the flash chip from being rewritten with standard Canon routines, no matter what they are trying to do (maybe by setting some write protection register, if the flash chip has any). Being able to emulate the flash would help, but still, the hardware might behave a bit differently, and unfortunately this can be model-specific; to find out what it does, one still has to run some risky experiments that could possibly result in camera brick (maybe recoverable with JTAG, but I have no experience with it). If the flash chip used by your camera is not listed on the
Datasheets page, consider taking (or googling)
high-resolution photos of your camera mainboard and attempting to identify it.