In addition to this, bypassing the upower client library reduces traceability (which is a big advantage of using client libraries to wrap dbus interfaces), and that traceability is required for problems exactly like this (ie, it's easy to find consumers of libupower and we have processes for library versioning if you want to break the API, but it's much more difficult to trace consumers of the raw dbus interface or properly version it if you want to break it).
I agree with Evan here, and it's not clear whether hughsie agrees with this approach either (see http:// lists.freedeskt op.org/ archives/ devkit- devel/2011- March/001056. html). At this stage in the cycle, we shouldn't be breaking public dbus API's like this.
In addition to this, bypassing the upower client library reduces traceability (which is a big advantage of using client libraries to wrap dbus interfaces), and that traceability is required for problems exactly like this (ie, it's easy to find consumers of libupower and we have processes for library versioning if you want to break the API, but it's much more difficult to trace consumers of the raw dbus interface or properly version it if you want to break it).