Meh, we need AI to understand API interfaces automatically and can communicate together seamlessly, without any hard coding. That's when device to device integration gets REALLY interesting. Wait, isn't this just bluetooth + web?
I think an app makes a lot sense to initially bridge embedded devices (that may only support simple web interfaces or even lower level network messages) to smartphone browsers (which are currently oriented to handling fairly rich web interfaces from full servers).
But where it should get really interesting is if you make the app support a generic enough protocol that you don't need an app-per-device type, but the app/protocol can handle a wide range of generic embedded device interfaces without requiring a full featured / high performance web server on every embedded device. After that you could basically get the protocol supported at the browser/os level and the app disappears.
I agree with that statement in general, but I don't see what it has to do with Google's Physical Web proposal/idea. You'd want what you describe even in a world with only traditional networked computers.