I like the idea, and it would make the srcdoc easier than having to put all of the HTML into a single attribute (it can get really big).
Just wondering though, how many browsers don’t use / ignore iframes (probably because they are really old), and considering iframes are used to typically host/isolate potentially more problematic content (e.g. using the sandbox attribute to limit what it can do), you now have this potentially dangerous code running in the main DOM… I usually use srcdoc to contain the dangerous HTML, and the iframe content to put in some safe fallback for those older browsers.
I’m also wondering, browsers have a pre-scanner to look for resources later in the document (e.g. while waiting for some JS to load, they look ahead for any other images/JS to get)… I’ve not looked at the implementation, but I suspect these are very quick/simple, where I’m not sure if they will be cleaver enough to notice that the HTML tags are within an iframe, and might start downloading them (where an iframe might have a CSP that would otherwise block).
That said, I would like iframes to be easier to use - I think they make a great way to improve security on a website (it’s a shame the CSS working group, and the browsers themselves, still haven’t allowed the height of the iframe to change based on the content, without the use of messy JS).