Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increasing load times.
I don't see much future in an architecture that inherently waterfalls in the worst way.
It's really unfortunate that this style of architecture lost the battle. It's elegant. Data cleanly separated from presentation, small digestible entities, and it all kind of makes sense. But what killed it was the verbosity of XML, as well as its extreme pedantry that results in lack of robustness where a single error would kill the entire transform. Also transformation-based systems notoriously lack proper tools for debugging early on. Lastly, typically buggy implementations of pipelining in HTTP/1.1 made it so that you actually had to make those round trips. But conceptually we had all the pieces to make it work well back in the early 2000s.
To do this dynamically I serve the content as I wrote it with a single processing instruction that refers to a stylesheet. This is elegant, isn't it? It is less efficient than a static site, but not that different from a typical HTML: HTML, CSS, JS. It is also trivial to change it to build statically (or to embed all the resources and XSLT into individual XML files, although this would be strange.)
And if browsers supported alternative stylesheets it would be trivial to provide alternative renderings at the cost of one processing instruction per rendering. Why don't they? Isn't this puzzling? I think it is even in the specification.
Of course everyone is free to create things they want with their own abstractions, but let's not pretend that it's an optimal solution. Elegance and optimal are often at odds.