I would like to add the result of an experiment I made just now:
My personal bad-on-purpose example: I have a fantec USB3 case, some years old. With four WD Red drives in a RaidZ2. When I pull the power cord (of the USB device, not the computer) I can create some distinct error situations. Each pass required manual interaction afterwards. I repeated this several times, always writing data full throttle to a testfile. In all situations the pool got "suspended" and I need to fight with "zpool import" several minutes to get it imported again. It is not obvious if I have to reboot the computer, or not. Of course rebooting is the cleaner way - who knows the state of the OS internal buffers after disconnecting/connecting an USB-device like this? Sometimes one of those four disks is stated "removed", sometimes none. Always "zpool scrub" is necessary as there are several CHKSUM errors presented by "zpool status". The testfiles I was actively writing data to got damaged - the data "on flight" was not written successfully and those files were reported like "errors: Permanent errors have been detected in the following files: /tank/test/myfilename".
Never the pool was lost - and this is the important fact!
Of course ZFS on such an USB device is NOT recommended. I do not use it actively, this is/was just a test-setup. I was fine with the behaviour and I would not expect any internal SATA-drive or NVMe behave worse than this fragile USB construct. Neverthess...: ymmv!