Yes, and it has to maintain TCP connections with every push source you've registered, including re-connecting whenever your network situation changes. IMHO, this will lead to a lot of wasted bandwidth. Might not be a problem on desktop machines, but on mobile devices…

It already happens on mobile devices through APNs, GCM, and the like. Maybe mobile web browsers will have backing cloud services that use the mobile OS's recommended push server as a frontend to the mobile device? That doesn't sound like an ideal scenario though, considering that then the cloud service would have an enormous amount of user data going through it.

APN and GCM multiplex messages from all apps on a single TCP connection. That makes a significant difference.

That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.

well how do smartphones and apps deal with push notification in general? (i mean native apps)

The OS provides a messaging service. Applications can request differing levels of latency guarantee. The default on Android is to deliver immediately unless the device is off or sleeping, in which case it'll be queued for up to 4 weeks or until the device wakes up, whichever comes first. There is also throttling functionality, where an app that sends too many messages in a short period of time will find that its messages are only delivered when the device radio has to wake up for other non-throttled messages.

With iOS, Apple provides a service that event sources push their messages to, and a single TCP connection is maintained with the device regardless of the number of event sources. Google has something similar, if not identical.