The tl;dr is that a PWA implies an app which is based in the cloud. So suddenly you need a server, and you need to store user data, which means costs and dealing with privacy and security.
If something could be built as a native app without depending on a central server, it could also be built as a PWA without a central server. You don't need to store user data centrally at all, just because it's a webapp. You can just have the clients use localStorage or IndexedDB or whatever.
You still have to host the static files for the webapp itself, but that can be made very cheap.
Of course, API feature parity between native and web apps is a separate issue. But the argument about server costs doesn't seem like a good one.
Sure, but localStorage isn't really ideal for storing large objects anyway, because it forces everything to be stored in one big string-to-string map. It's great for small amounts of data such as user preferences.
There are other APIs that allow you to store binary data directly (which you'll probably want if you're storing large files) and also to use/request larger quotas.
I read the article, and I'm pretty certain he's talking about a traditional web application. When we speak of PWAs we're thinking of a set of APIs that let a web app behave like a native application. i.e 'installation' + service workers, background sync, IndexDB/FileSystem etc. You could probably make a self-sufficient RSS reader with what's available.
It seems to me that, ironically, PWAs are uniquely ill-suited for the type of non-corporate software where distribution outside mainstream channels makes the most sense.
The tl;dr is that a PWA implies an app which is based in the cloud. So suddenly you need a server, and you need to store user data, which means costs and dealing with privacy and security.