For a mobile device, you have a classic tradeoff between battery usage, network usage and timeliness of updates.
The push notification service built into a mobile OS is designed to try to give you the best of all these tradeoffs and it runs globally rather than per app (which is usually more efficient), though it gives you somewhat less control over implementation details.
When comparing socket.io vs. polling an API, socket.io (and more specifically webSockets) were designed to be a more efficient way of getting asynchronous notifications from a server.
In socket.io, you create a socket connection to the server. That connection stays open for the duration of your app (in the foreground) and, at any time, the server can just send you data and you will receive it immediately when it was sent. Because connections can be lost and the endpoints are not necessarily notified of that immediately, socket.io uses small heartbeat packets that are sent on a regular basis between client and server. If the heartbeat packets stop being responded to, then socket.io assumes the connection has died and will close the original socket and attempt to create a new connection. It does all this transparently and automatically for you. This heartbeat, however, has some undesirable ramifications for mobile. The data sent is tiny so it's not really an issue of bandwidth usage, but every transmission from the mobile device uses battery and that can be relevant if left to run for a long time. The heartbeat interval in socket.io is configurable. It can be turned off (not recommended) or the time interval can be set to a longer time.
Both the OS push service and socket.io are very efficient from the server-end of things because the server only does work when there is something to actually send to the client and does not have to field regular requests where there is nothing to do.
The only possible advantage of polling here would be if your desired update interval was long (e.g. once an hour) or it isn't usually on and is only used occasionally. Then, you could just send an Ajax call each hour or upon demand and the server wouldn't have to do anything except answer the occasional Ajax call. If the desired interval is shorter, then you're probably going to want to use one of the true push mechanisms (either the OS push or socket.io).
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
