It's surprising by importance but not by size, which is actually a sweet spot for evaluating a new systems language - a small dependency that everything uses.
That's something that comes up more often, because many feel this shouldn't be in the kernel in the first place. The problem is that there hasn't been a proper userspace alternative with similar performance characteristics.
I think putting this stuff in the kernel is rather silly, but I'd rather have it in the kernel than bring back the rift between Android and Linux.
I'm not sure how you'd port binder's security guarantees to simple shared memory. Binder is more than just IPC, it also provides an RPC mechanism as well as some isolation capabilities.
I'm sure it does more things that make it useful, and that it provides a practical programming model for certain platforms, but it's certainly not the lowest latency way to do inter-process communication.
The only thing that needs to live in the kernel is fast message interchange. And that could also be used as the base mechanism to move all(!) of the drivers out of the kernel.
Since Android 8 that the only in-kernel drivers are what the Android team considers legacy drivers, aka standard Linux kernel drivers pre-Project Treble.
Hence why modern Android drivers are called Binderized drivers.
I was just mulling this over yesterday with the story about USB tablet driver regression. Running drivers as user processes would essentially give the kernel a stable ABI. But then we'd see a proliferation of closed-source drivers - there wouldn't be motivation to upstream hardware support anymore. Is that a hidden goal behind this fast IPC thingy?