Additionally a lot of the APIs if you go underneath, including native code components, are exposed through few variants of Binder (BeOS-derived IPC for the uninitiated) including userspace drivers.

Binder APIs very much do not follow C ABI other than the part where you deal with wrapper around ioctl()

This is entirely unrelated to the point made.

Binder is just C++ with a thin IPC compiler, more or less similar to any IPC idl. Could be sunrpc, but Google wanted a c++ wrapper.

But in any case this is completely irrelevant, because there is no such thing as a "userspace driver" (unless you're speaking about hurd or plan9). Drivers are by definition kernel-space code (which on Linux is either built into the kernel, or is a loadable kernel module). Those binder wrappers are just a convenience layer, underneath it's all still Linux, /dev/video0, v4l2, and so on.

Linux actually has pretty long history of userspace drivers, and multiple kernel drivers have as their main if not only logic a way to link hardware interface with userspace app, or just providing transport interface. And android heavily uses such interfaces from day 0, which is why you have separate binder instance on Android for drivers.

As for Binder being C++, no it isn't. Historically it has connection with C++ due to how it was used, but like other IPC it's not bound to C++, and arguably given how it is structured compared to some other options there's even less C++ specific stuff in it.

Also, IIRC the use of Binder predates acquisition of Danger (?) by Google

It's just demagoguery. Windows could switch to Linux kernel if Microsoft cared enough to invest into Wine. But this will not happen any time soon.

All smartphone drivers would have to be rewritten for a different kernel.