It’s for Push Services. Here’s why it is important, almost every mobile client is plagued with backgrounding issues. So when the app is in the background or your phone is locked the app no longer responds to the keepalives or new incoming requests from the PBX system. So that means you are not getting calls. Kind of pointless, eh?
Now with the Push Services, the client registers to the push server which in turn registers to the PBX for the client. Now the PBX is sending keepalives and new requests to the push server which allows the PBX to responses to keepalives (from the push server) and when a new call is sent to the push server it sends a wake up to the app bringing it out of the background to receive the call.
Bria has this for its users and even Zoiper’s commercial offering has this for the users. I bet there are more commercial ones that do this as well. Because they all realize what this problem is and it needed a solution.
So is it an additional point of failure, sure but technically it could run from the PBX but then that means everyone has to maintain it and well with most PBXes being behind NAT it makes push services harder to do. It’s basically the right way to do mobile softphones for SIP if you’re actually serious about your softphone getting requests and calls.
I hope that was cogent enough for you.