He touches on navigation, but misses talking about the Android hardware back button, which in PWAs hooks up to the same mechanism as it does in the browser: it goes back. This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Imagine you are viewing a list of contacts and you: tap on a contact, tap edit to get the editable version, make some edits, tap save to get the change read-only version. In an Android app, you'd expect hitting back at this point would take you to the contact list. Here, it will take you back to edit mode for that contact.
There is also little to no support for apps that want to use large or arbitrary amounts of storage (imagine spotify with offline support as a PWA), or a framework to allow users to deal with that. With a native application I can store as much data as I want, and the user can see what data I'm using in the app list, and clear my data to remove it, or simply uninstall my app. With a PWA you're limited to some confusing arbitrary amount that is unpredictable to the application, the user cannot see this amount anywhere, let along aloneside normal apps where it should be, nor can they reasonably clear the data.
We are currently solving both problems, ironically, by wrapping our app in a native android app: solving the former by overriding where the hardware back button navigates to, and the solving the latter by (no joke) shipping a patched version of chromium with the obtuse quotas patched out.