I think Tolmasky's point was that, even though Web.app embeds the same UIWebView as non-Apple native apps, Web.app was written by Apple. Apple could enable Nitro JIT for Web.app because its native code was written (and audited) by Apple. The only third-party code executed by Web.app is JavaScript that is already assumed to be safe enough to use the Nitro JIT in Mobile Safari.
It makes a heap of assumptions though, and feels kind of like a non-techie person saying "why dont you just whip up a GUI app to trace my IP".
Enabling Nitro JIT for UIWebView for some applications without enabling it for every app in the app store is probably more difficult than toggling a switch.
You seem to confusing facts with claims on a blog written by a third party. It's not hard to believe Web.app (the process which runs home screen apps) uses UIWebView or a close cousin, but neither you nor Gruber (or anyone on this site) has offered any evidence of that fact.
I find the fact that Web.app behaves exactly like every other application that uses a UIWebView to be very compelling evidence that Web.app is an application uses UIWebView.
The alternative appears to be that to create Web.app they went to all the trouble of reusing the Mobile Safari code, and then methodically went through and broke things such that it behaves exactly like every other application that uses UIWebView.
This would seem like an unreasonable way to get an application that behaves exactly like an application that uses UIWebView.
The way Apple implemented Home-Screen Web Apps was by placing a thin wrapper around a UIWebView.
Hence, Home-Screen Web Apps are not like Mobile Safari at all in actual implementation.
They are, instead, exactly like an iOS application developed by a third party developer who put a thin wrapper around a UIWebView.
Hence, they do not get the same special privileges as Safari Mobile.
That is a fact of their implementation.