I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. I like Gemini, a lot, and I think it could serve as a "document web" very well, except it's missing certain document featur…
Why does it have to be so siloed? What if I want documents with a slight bit of inactivity? Why must I go through two different protocols? What if I want to read a paper next to the Juyter notebook that made it? I think it should be the clients job to take whatever slice of a richer universe it wants. This also stops duplication of effort, why maintain separate protocols and clients etc. It’s just a search issue, the…
A dedicated document browser would likely almost always blazing fast, regardless of the machine it was run on and the network over which the documents were transferred over. It could have features that would make no sense in a web browser but greatly enhance the experience of reading and navigation. It could reasonably cache nearly everything the user visits (since it's practically all read-only and small) to reduce server load and increase speed. In a nutshell, it could be far better at specifically working with documents than a web browser ever could, even with a laundry list of extensions installed.
Additionally, it would actually be possible to write brand new competing document browsers due to the vastly more simple specification, which is something the web will probably never have again.