1) security. Container breakouts are much more common than VM breakouts
2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server
For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL.
Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp.
Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon.
TIL that binderfs is a mainline kernel feature now,
Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
Containers are native executables (with cgroup rules sprinkled on top). If Android does not let you call exec in the traditional way then you have a problem.
Also you're moving the goalpost with this comment a bit. My original comment says "may benefit from" being run under a "vanilla" kernel, as opposed to saying it would be completely non-functional under Android's kernel.
1) security. Container breakouts are much more common than VM breakouts
2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server