You are correct. Binder plus the userspace security policy framework in android is very much like policykit/dbus. The major difference is that Android makes use of their own special IPC mechanism (Binder) because of what they saw as deficiencies in DBUS at the time.
I don't know of many people using Linux capabilities currently (although I don't claim to be an expert on it.) Dan Walsh and others at Red Hat are working on using file capabilities to remove the need for suid on binaries in Fedora. If you're going to make a capabilities system you need to make sure you do it right otherwise you miss the benefits of having it in the first place. That's why they really need to be auditing what actions go under what capabilities and breaking them out as necessary. People say the same thing about the complexity of SELinux. I personally find capabilities and all of their semantics far more complicated than any SELinux concepts and I was introduced to both at the same time.
I think the solution here is to go over all the calls to capabilities and make sure that 1) they are the correct capability, and 2) if they are not that there is the appropriate granularity present for those capabilities. The way that LSM is setup currently is that the capabilities module is the default security model unless something else is specified and then it is chained together with whatever LSM is loaded. So it is there regardless of what you do so we should do it right.
I personally would use SELinux instead of capabilities but I do see a benefit to making use of capabilities to remove suid behavior in the system for when someone decides to not use SELinux. In general I'd say SELinux is a superior solution because it actually controls access to specific objects in the system where capabilities give you access to entire classes of objects. For example with SELinux I can limit an application to binding to a specific port. With capabilities from my understanding the only thing I can do is say whether or not a program can bind to ports.