What Brad has proven is that you can't reliably protect a level of the system at that level. That if you have access to the kernel address space that anything in the kernel is fair game and you need a protection at a lower level to help address that (hardware for example). With that same reasoning you can't protect an application layer framework solely at that layer. If you think that the way to secure usespace is by properly auditing all userspace code to make sure its all ok then we'll have to disagree.
For an example to the second part of your response. The only thing policy kit will get you is a yes, no, authorize answer. It will not protect you if there is a fault in the "mechanism" that is using policy kit. If you find a way to send a bad DBUS message which allows you to hop the policy kit check through some exploitable code then you can still run. As a matter of fact there was a race condition in one of the policykit authentication agents which allowed you to exhaust the pid space and run any policykit action as root a while back. This is just skipping the authentication. In a similarly crafted situation above if I can get some sort of arbitrary code execution by this privileged mechanism I now have the ability to do whatever I want. Without one of the security mechanisms I mentioned above you're relying on the correctness of the userspace code to enforce access control on other things in the system. That's just not acceptable.
To address your third question. Restricting access control based on users has long been debunked as an acceptable mechanism. Whether it be SELinux, or SMACK, or Tomoyo, or GRSecurity RBAC, or any number of other mechanisms people have said time and time again that binding permissions to executing code is much more effective than binding it to a particular user. For example if you bind it to the user anything that user can do can be done by any application the user runs. So an exploit in the web browser can read out the users SSH keys if it wants.
To respond to the last part of your response. Its not a question of anti-spoofing. Trusted path is an important area where Linux is lacking but it still falls to a problem that actions are not bound to specific applications. If you bind an action to a user any policykit enabled program can authenticate and send a related message to a mechanism regardless on whether or not it is supposed to send that message type. I would really like to be proven wrong here because if I am not wrong this is a large hole which from what I can tell is only mitigated by putting in an SELinux dbus policy.