Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other?
The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message and have thousands receive it. But as you note, the biggest boon of a push service is the realtime nature that allows for immediate updates to reach your consumers. However when doing pushes you really don't ever want to be pushing large data sets if you're broadcasting, and you're also at the mercy of the third party push service you utilize (if you utilize one).
The purpose of a poll is to check for data differences periodically, where the update period can have an acceptable SLA of inaccuracy up to a certain time period. A poll will require all your clients to request the data periodically which will mean a connection being requested for every running client, and the necessity of a live service able to monitor that data accurately to serve it up to the pollers. Having accurate data to serve up means some data persistence which will take up disk and maintenance time.
So from this we can see that if you have concerns about network traffic or the maintenance of a service (which means possibly authenticating/authorizing requests, logging them which takes up disk space, all the normal requirements of maintaining a service) then you don't want to force clients to poll. However if the use case requires transmitting a particularly large data set or you can't be tethered to a third party's API which may change in time as well as their SLA or charges, then a home grown polling system may be applicable, though the maintenance overhead may be significantly more. Alternatively you may already be running service and have the data persisted such that the polling is a light addition to already in-place infrastructure, which makes polling more desirable.
Though to the central point you make you are correct; if real-time is necessary, polling will not do. If it is not, then you just have to do the math on how periodic the data can be checked multiplied by your client base multiplied by your data set size to decide if the network cost is going to be worth it, or if a push service would be better where you can always just push a change event that let's them request the large data set in a secondary step (though atomicity of these steps may be something you need to be careful of depending on the criticality of the data).
