So I read the policykit documentation last night and mechanisms can be either daemons or normal executables. DBUS activatable daemons are still daemons. This page explains a typical policykit interaction complete with client, mechanism, and authorization agent. There are more than just allow and not allowed responses from policykit. There is also an authorize return which kicks things off to an authorization agent which handles the 8 or so different authorization modes that can be specified by policy kit. Going back to your earlier statement yesterday it seems your argument boils down to we should write code properly and rely on userspace to police itself. It also ignored the fact that the set of actions that policykit is policing and the objects it is protecting are completely disjoint from the objects that the kernel protects. policykit isn't going to provide you any sort of access control to the things under the hood. The way I read it policykit is more of an authentication mechanism than an access control mechanism.
As a side note its unfortunate that people aren't using the SELinux extensions to DBUS which would make policykit more effective. From what I can tell any "client" can send any message that a user is allowed to a policykit enabled "mechanism". The information transmitted with a DBUS message for policykit is uid and pid(and potentially an SELinux context). So in theory I could exploit an application and have the user think he's typing in his password to say change the system time but instead send a DBUS message to perform some other action. James Carter a long time ago extended DBUS to be a userspace object manager for SELinux and its a shame we don't see distros using that to ensure that certain clients are only allowed to talk to certain mechanisms. If it is restricted in some other way I'd like to be proven wrong but the documentation doesn't seem to mention anything about that.