Also, to answer your question, not it's not the same as a website because it will be a native Android app with the ability to communicate with the Android OS, like any other Android app.
The possibility of things — in terms of improved UX — that you can accomplish with instant apps are infinite. It all comes down to how you want to use it.
If I'm clicking on a link I want to open it with my browser, not with some app. I find this extremely annoying with facebook and even the news carousel already.
I can't open new tabs, copy the url, switch to other tabs like I would in the normal browser. This is extremely confusing and I don't how this benefits me in any way.
A better implementation would have been to have a popup with a list of compatible apps to run, including an option to run it in a browser like any normal link.
I really hope the NFC bit is opt-in by default. I don't want to have to manually disable it every time I get a new phone. In fact, even if I've opted into having the SF Park app run when I'm near a parking meter, I want the option to "reject" it just like I do when I get an incoming phone call.
The website itself specifies which app should be used by publishing a Digital Asset Links file. (https://developer.android.com/training/app-links/index.html)
Full OS access could mean permissions per page - could be awkward or ok. Much of the app vs. webpage debate here is the same as always - though offline advantage is gome.
There shouldn't be any problem classloading an Activity, use reflection to instantiate, and treat as you would a runtime Activity (as opposed to being declared in AndroidManifest.xml). But I haven't actually done this; could be some gotchas in incorporating runtime a Activity into the GUI.
IIRC google had a few hits on classloading Activities.