spiral While my general preference is for each application to implement its own direct-push protocols, there are a couple of drawbacks to this;
1) Poor implementations (such as polling every 2 seconds, or excessive reestablishment of the connection) may cause an increase in battery consumption. This doesn't apply to GOOD implementations, which really won't consume any appreciable amount of battery.
2) Google has forced us to use what is called a FOREGROUND SERVICE in order for services to keep running perpetually, which comes along with the side-effect of always having a notification annoying you, so after several programs are running push notifications, your notification panel can get quite crowded. Basically, google is trying very hard to force everyone into using THEIR push notifications system, which gives them access to a lot of data.
So UP is there to keep it down to a single service where everything else relays through it, allowing it to theoretically drop you down to a single foreground notification, and if their implementation is good, then it won't cause excessive battery usage.
There are also drawbacks;
1) If you don't have your own server, then someone, who is hosting your UP instance, can detect where your notifications are coming from, this is a privacy concern that doesn't exist with direct push implementations, since you will periodically make connections to those servers anyway, so nothing extra to see here.
2) It depends on everybody agreeing to use that particular implementation, which is unlikely in the extreme -- you'll have other services anyway.
3) It creates a single point of failure, the UP server goes down and NONE of your notifications go down, whereas keeping separate implementations means that if a particular service goes down, it won't affect any of the others.