I don't really see a difference, as a consumer. If the AV sits at the kernel level or between userspace and kernel, it's still sitting below userspace and can do whatever it wants to the system. Sure, if I trust the kernel is better written than the AV software, I may have a few extra guarantees, but that is not a given and anyway it doesn't mean I can confidently run an AV I think may be poorly written.
It overall seems like a more complex solution that has more chances of being wrong. I would bet the core reason Apple did it was control to lock down their own control of your OS, not any security reason. Perhaps it also simplifies their development somewhat, if they can rid of some stability guarantees for some in-kernel APIs that AV would have needed.
> it's still sitting below user space and can do whatever it wants to the system.
I don't know much about the Endpoint Security extension, but for Apple's network filtering extension they actually DO address this!
The code that runs on every network call is heavily sandboxed and can't communicate at all with the outside. Its only action is emitting some basic signal like "block" or "accept". This means that while the system extension can evaluate all your network communication, and block what it chooses, it can't exfiltrate the specific content. I might have the details wrong, but that's the general intention.
But the security benefits aside, I think the real reason for preventing code from running in the kernel is about stability and not security. Buggy code won't crash the system anymore. They can also enforce stricter performance requirements.
(And at the moment, you can still run kernel extensions on your own system if you really want by disabling SIP and other things, it's just infeasible for any AV vendor to have their customers step through that very onerous process.)
It overall seems like a more complex solution that has more chances of being wrong. I would bet the core reason Apple did it was control to lock down their own control of your OS, not any security reason. Perhaps it also simplifies their development somewhat, if they can rid of some stability guarantees for some in-kernel APIs that AV would have needed.