Sure, tabs can load static assets from a read-only cache instead of re-fetching everything from the origin (be it an in-browser cache run by the browser kernel, or a Web cache somewhere between you and the origin). But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? When would it ever make sense for multiple tabs to directly access each other's runtime state?
I'm not sure that your example prevents the implementation of per-tab javascript VMs. Wouldn't the browser be designed such that its kernel mediated all tab-to-tab runtime state queries? Then, tabs wouldn't directly access each other's state, and the kernel would interpose security policies (such as same-origin-only requests) between tabs regardless of a tab's behavior. To keep this arrangement transparent to programmers, the tab's javascript VM would map access to shared state (like a window's opener) onto the appropriate call to the kernel, obviating the need for direct inter-tab memory access while preserving compatibility.
Layout and compositing need to be cross-origin; the Web implicitly allows cross-origin resource loads; and (as was raised above by pcwalton) browsing contexts like windows and frames need to function as if they're running on the same thread and can potentially be shared. All of that is to say that all of the potentially shared state makes it extremely difficult to bind a web origin to a process for security purposes. It's a hard enough problem that a team of Chrome engineers has been working on it for a few years, and are only now approaching an alpha implementation.* And that's many years after Chrome was entirely multi-process with sandboxed web renderer processes.
That would break the Web, because you would introduce data races into JavaScript. (Think about the granularity of synchronization on the objects you would need.)
