Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.
People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it's pretty darn close.
A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build and use glibc.
Also, I get the lack of control, but that really isn't a major issue. The linux kernel pretty rarely adds new userspace additions. By and large the majority of work that goes into the kernel is around new drivers and fixing drivers. Even when there's kernel level features, it's very often not a userspace thing but rather things like new schedulers.
There's a reason MS didn't see the same approach as being too terribly crazy with WSL1, and those are very different systems. Heck, there's a reason cygwin continues to exist and work.
POSIX provides an API, not an ABI, and that API kind of ends at libc. Being compatible with Linux at an ABI level means being able to provide the same syscalls in the same way as Linux does. Not all Linux syscalls map cleanly to POSIX APIs, and in general xnu has lots of different concepts that make it somewhat cumbersome to adapt to what the Linux kernel does. The example of this is Microsoft with WSL1; they gave up not because Windows was too shoddy but rather because people want ALL of the kernel, which is a moving target anyway. it's a waste of time not to simply run it in the first place, virtualization is cheap and you get the real thing, with no quirks