Sure.
RSS is a neat standard, but if you're writing your own app, you might as well use a custom JSON payload that's exactly what you need. If you use RSS but never actually use an RSS reader or expose it to the public, you may end up deviating from the standard, or doing extra work to be compliant with the standard that never gets used.
As far as push notifications, the reality is that "push" is a bit of a marketing term. Every time your phone wakes up and gets on the network, it contacts Apple or Google and sees if there are any pending pushes to be delivered. By using the "push notification" systems, you get to piggyback on that highly optimized connection already provided by Apple or Google. These pushes have to be much smaller than your typical RSS feed and are intended for high priority delivery.
An alternative, if you don't want your data going through the "push" networks, is to have your app "background fetch". You might want to do this if it's too much data (like an RSS feed would be) or if it's sensitive data (Apple and Google can obviously read all push messages). In this case, the iOS and Android have special "background fetch" use cases, which gives your app a chance to pre-load data. News apps are the canonical example.
> it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client
Mostly because the realtime queue already exists, it's provided mostly for free, it comes with extra features like sounds and badges, it was available before background fetches, and business people know to ask for "push" by name.