Here's some context on this with illustrations and videos:
Given this motivation, portals are a single solution to two problems. In my mind, it would make more sense to divide the concept, and create two separate, complementary features:
1. A way to eliminate perceptively slow page transitions, perhaps with an approach like turbolinks: https://github.com/turbolinks/turbolinks . Require minimal changes to existing markup, and allow <a> to use the new, more-seamless page transitions.
2. A new UI element that is like a modern take on the iframe: the <portal>.
The downside to the approach is that it cannot stream the HTML response, which is what browsers do, so you wait longer for the page to complete. But if you have a fast enough server then the gains from not rerunning scripts probably helps more.
Of course there are techniques to improve page load time without turbolinks (using async script tags for example), but turbolinks predates many of those.
server-side rendered html by its nature is also more accessible then spa/vdom frameworks, that tries to be fast by skipping the dom and re-implementing it in js(suckers).
However, what I was alluding to in my comment was the background-load-and-swap approach used by turbolinks. An <a> could be enhanced to load the next page in the background, and then swap in the content. When combined with smart pre-fetching and pre-rendering, this will yield page boundaries that feel seamless.
Note that this is exactly how portals will make browsing feel faster. My abstract proposal is merely to make this a more general feature that can enhance plain links, rather than coupling it to a new UI element.