I think the DB issue was the result rather than the cause of the issue.
Yes, but from the code it can’t happen, so there is already something bad here.
So if you use only the DDF for the _TZ3000_w0qqde0g in a “normal world” it need to be skipped for the problematic plugs, so can be better with the swoop correction that prevent bad DDF be seletected.
Ha yes, can be a good idea to test on another hardware, to be sure it’s not from the OS (a library version)
A post was split to a new topic: Xiaomi bulbs do not respond after backup and restore of Phoscon Backup
I went ahead and copied a backup to a Pi 4 with another Conbee II stick and restored the backup of 2.14.1. And low and behold: even after adding a bunch of Tuya plugs it all seems to keep working fine!
So somehow there is a combination of factors that causes issues only in Deconz running as a Docker container on my Synology NAS. I am wondering what could be that different in the Docker image, and what can explain the problems only after I add Tuya plugs to the equation? Any clues?
[Update] While it’s not a solution for the issue with deconz running in Docker, I’m marking it as a solution since it works on my Pi4. 
Another update: I also tested with 2.15 beta, hoping that that would solve it but unfortunately, on my NAS in Docker still the same problem. Now I am really starting to think it’s the Docker Base OS. I did a full restore of the fully working Pi4 gateway backup.
I asked the owner of the community docker (GitHub - deconz-community/deconz-docker) repo, but he replied he does not know exactly how to build a version with a new/other base OS? is there anyone here who knows how that works? And I was also wondering if it has been considered to offer an officially endorsed Docker image, much like the pre-built SD Card image for Pi?
[Update 06/22]
After having used the Pi4 for a few months without any issues I decided to play around with macvlan network a bit. And low and behold: that solved the weird delay issues with deconz in combination with the Tuya plugs.
I added a “macvlan” network to Docker and reconnected the same deconz container to that network instead of the default “bridged” one! The added benefit is that this also allows for a dedicated IP per container, which means less hassle with port conflicts. Something like: How to setup and use a Docker MacVLAN network on a Synology | Sysop's blog
I can’t really explain why this solves this specific issue, but it did and I can turn off the Pi4 for now!
I prefer the DSM docker solution because it means easier setup/upgrade (just download latest and reset the container), automatic backup of the database and less maintenance. in general.