Those have been part of the web standards for ages (serviceworkers, web notifications).
Weather, headline news, sports scores, non-urgent messaging could really use silent push to get data synced whenever you want to use it, but clearly not with Safari on an iPhone, and I don't think you can do it on Android without an app either.
It's exactly this kind of wasteful resource usage and the accompanying notification spam that drives me to avoid native apps in the first place.
Given where I live, my big one is ferries. When I get on the ferry, it's a nice time to see what's going on in the world, and what the weather will be like, and maybe check work email (before I retired), but I can't do any of those in an online only world because cell coverage is very spotty. For the small handful of apps that manage a data store on the device, I can use those and catch up on things and queue outgoing messages. I'd like to make some more things for me, but native Android development is beyond my patience, and PWA doesn't have the capabilities, and some horrible blend of the two is what's wrong with today's world :p
Google, being Google, have developed a Background Sync API [1] that can achieve background sync without notifying the user. This also extends to Edge and Opera and such because they share an engine.
I can see the use in a system where you sync data to a device that has intermittent connectivity, but I've honestly never seen such a system work for native apps when I've had intermittent connectivity myself. Even Google's automatic weather notifications don't show the right weather until I tap then and a web search loads.
Your background sync requirement is a nice to have and it'd certainly be a reason to use the app instead of the web version of a service for users with limited connectivity, but they're not really strict requirements for most applications. The applications we use today mostly consist of scrolling and connected browsing, with some data management and sync in between. For example, I browse twitter through the web app and outside the "fleets", whatever they are, that Twitter simply decided not to port, I'm not missing anything. I get notifications, I can browse, I can compose, there's really nothing more I need.
In the end, Apple's (intentional, probably) nerfing of Safari is what primarily stands in the way of proper mobile app support on the web. Notifications are a feature that I'd say most apps would require these days and Apple simply refuses to allow them. There's plenty of other WebKit gripes that developers have to overcome to program for iOS, but the complete lack of certain features is absolutely the worst.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Push_API [1]: https://developers.google.com/web/updates/2015/12/background...
That said, you're right that most apps dont truly take advantage of background processing. What you have to understand is that the lack of background processing is what keeps notifications unsupported on iOS. Not only can you not support push messaging natively, but you can't _replicate_ a push messaging system either because there's no way to run code when your webpage/PWA isn't in the foreground.
Otherwise, yeah.