Putting some thoughts behind this… 
1- when the cam is bricked it still can “READ” SD content (otherwise the LED would not turn purple)
2- bricking is apparently not generalized on v3s as some people are not affected by this issue
3- bricked cams can’t complete the boot steps even with no SD cards in the device
I am guessing part of the initializing process (booting) is based partly on ReadOnly ROM (logical practice to be able to recover from an update that went wrong for instance) which then reads the content of a Writable ROM which appears to be updatable (since an OTA update doesn’t require an SD card to update the cams firmware right?).
Conclusion part of the writable ROM somehow gets corrupted while updating the cam firmware OR during regular usage (based on my observations).
You would think that a manual firmware flash would fix this but it doesn’t, which tells me that the flashing code “WRITING” is also updated by the firmware (meaning when the writing code gets corrupted it can’t bring the cam back even when doing a manual flash) and appears to be accidentally updated/corrupted during regular usage (I would guess the firmware ROM writing code shares a cache with the filming code and so one will accidentally write where it should not when a specific set of variables match triggering the writing bug ).
My theory?
It would be technically possible to fix the cams by writing (with the proper tools) directly in the writable ROMs (bypassing the cams own writing code) a clean writing code. But since there appears to a bricking bug in the cams there’s a chance that the problem would happen again.
Question do we know of any Firmware version where no nonsense bricking occurres? That firmware may be the only way to prevent this issue from happening until wyze has done its homework of fixing what appears to be a firmware bug. Otherwise cam v3 are living on borrowed time and luck.