I don't think this is ultimately an IFPS problem. How I've always understood IPFS is the protocol being a decentralized blob storage. You would use it in place of a CDN, to share files, or other building blocks for something higher-level. This is in contrast to browsing where there are established semantics on addressing absolute and relative URIs, and clustering relevant content under hierarchical addresses in the URI path.

The author insisted on doing this on bare IPFS but I think this is (vaguely) analogous to building a website based on IP addresses and port numbers, not URIs. To the point: the semantics just aren't there.

I could imagine an IPFS based web site being built with a local URI resolution map as part of the bundle of objects that is the web page. The sub pages would refer to symbolic URIs like before but the browser would also download a site map that links URIs to actual hashes of the latest revision, and resolve references like "foo/bar.html" or "/root/foo.html" based on the map. Or a proxy could do this transparently, translating URI requests to hashes and fetching data directly from IPFS, then serving it back to the browser as if it was downloaded from "/root/foo.html" instead of "ipfs://50ad443758222efea0286f3a94db2c25".

The top-level entry to the web page would basically be this URI resolution map which, as content-addressable, would effectively refer to a single revision of the web page. This could be implemented as a separate URI scheme, like ipfs-uri://bb9f6cbcc28829b57dd25102f67b9d37/main/news.html where ipfs://bb9f6cbcc28829b57dd25102f67b9d37 would point to the URI map and the URI handler would resolve the relative URIs such as /main/news.html based on the offered mappings.

But all this does require extra lifting from the browser or a proxy. I don't think IPFS as designed is feasible to replace something like HTTP which was explicitly meant to work with URIs.