Horst

I don't know, but what you describe is that OP1 is essentially able to run from RAM (network I/O mainly) so not so much storage I/O which then lowers the change of corruption. For OP2, is quite heavy disk I/O it seems, also torrents writing is tricky for some filesystems. 
 
If you want to know more why and how w.r.t. corruption, use Btrfs instead of Ext4. It still can be difficult if HW caches do the wrong thing, but you can make metadata duplicate and also play with commit time. I have a Pi3B running from SD-card and 4T 3.5i HDD via USB attached. It runs Debian Testing (Trixie now) , FAT bootfs and Btrfs rootfs with hourly snapper and also manual extra snapshots if I do upgrades. Also HDD is Btrfs formatted, 'dup' profile for metadata 'single' profile for data. I gets hard power cut every day at least once as solar powered. I do not do any UPS like noticing, also the power loss might be during a btrfs send|receive transfer, that will then fail, but in my script I delete read-write snapshots first as they should be read-only (so were correctly finished). No data loss or corruption during years. I just have a very simple guess about the amount of sunlight, which might be almost zero for days in winter.
 
On a Pi2B that seems to have damaged GPIO pin 4 and was using a bad brand SD-card, I could quite perfectly see when corruption started, which files you see when you do scrub. It was a logfile and some other file that were recently written, but unimportant, so I could still do a btrfs send of a snapshot of the rootfs to my local laptop new SD-card. I know how to create bootfs for Raspberries.
 
For my NanoPi-NEOs running Armbian I changed rootfs Ext4 into bootfs Ext4 + rootfs Btrfs. You can also use Armbian build to generate that off-the-shelf, I would now use FAT for bootfs as that matches how UEFI computers are organized. You also need extra write of U-Boot, that is not needed for RPi or UEFI.
 
An Ext4 filesystem can be turned into Btrfs in-place with tool btrfs-convert. If it is a rootfilesystem where the OS runs from, you still need to create an extra bootfs though and so also change fstab and also as a consequence the partition table and organisation.

data corruption can always happen when there is a power outage. Could be by chance that one device suffered while the other didn't.
Best way to prevent is as guessed a small PSU which ideally tells the device 'there is an outtage, please shut down before I run out of battery".
 
Having OS or data or microSD, eMMC or NVMe does not make a difference since the OS decides when and how often data is written. NVMe are even more fragile since they often come with an internal cache themselves that is emptied onto the actual flash asynchronously. 
Disabling write caches may lower chances for data corruption but for once can decrease performance a lot and for the other significantly decreases the lifetime of microSD cards.

I tried to find the problem, but I still think that their SD card is broken. It is not true. It's just that Linus himself spoils files when the power is removed abruptly! Therefore, you can get bus error and similar scary messages

The topic is no longer new, but I have not found the reason and its solution!
 
If you turn off the power (just pull out the wire) then you can get a non-working system. 
As I noticed, the files opened at the time of launch are broken. And some files such as /etc/boot/armbianEnv.txt in general, they are recorded with some kind of garbage!!!
 
Because of this, your settings fly off! For example, I use ttys1 and this option is registered armbianEnv.txt , but after the power loss, there is just terrible garbage in this file, as if the memory dump fell there!!! For example, I still use dotnet, so it also breaks down and does not start anymore!! When you try to run dotnet from the command line, you get a bus error! Of course, deleting and reinstalling it solves the problem. You may also get problems with apt!
 
I certainly expected this from windows. But for linux to be somewhat unreliable is a tin and a disappointment!!
Why does this happen and how to treat it???
 
Now I have made a sh script to check the integrity of files and restore them. But these are crutches and a shame for linux!!! Maybe arabian is crooked and unreliable? 
or is it a disease of all systems???
I must say right away that the SD card is normal! This has been tested on 10 minicomputers. It's the same problem everywhere!