While that isn't really recommended, it shouldn't be a problem either - at least modern targets have image meta data attached (which include a checksum) that would sysupgrade to refuse flashing (and simply rebooting instead) a corrupted image (unless you --force the flashing). sysupgrade also detaches from the network before it actually starts flashing, so a loss of connectivity wouldn't cause any harm either - a power loss during the upgrade would be a real issue though.
which is weird and shouldn't happen (again, a sudden powerloss during the flashing can be fatal).
If you have a serial console attached, you should see what is happening and be able to describe (and paste the log) a bit more exact, there are basically two options:
the flashed image fails to boot
either the bootloader notices something amiss are reboots the device in close succession
or the kernel/ firmware starts to boot, before failing a little later in the boot process (and probably gets rebooted by a watchdog)
the device suddenly shuts off (which is what I'd read into your description, but what's also a bit less likely to happen as a result of your described failed flash), here it really matters what exactly happens at which point into the boot process
The former case should be fixable (quite easily), as you already have a serial console attached (and working?) - as long as the bootloader is undamaged, can be interrupted and instructed to load an initramfs image for fixing.
The later case sounds more like a real hardware damage, which is unlikely to have been caused by an interrupted flash process.