The web is also started out as a distributed filesystem; it's just not replicated (unless you use a cdn). In the begining the web had no cookies, javascript, animated gifs, etc. So, ipfs adds resilience and scaling to the web.
Using ipfs for serving up static content instead of a traditional http server can make a lot of sense. Long term browsers might learn to interface with ipfs directly and simply specify hashes of what to fetch in their dynamic content.
Eventually that too might be content addressed. If you think about a modern docker based system, basically all you tell your server is an image name and a version tag that points to some content hash of the image it then goes and figures out what to run. Right now mostly you still get that stuff running on dedicated hardware provisioned ahead of time. But with e.g. lambda's that is less of a thing and the code gets provisioned to hardware just in time.
Building a docker registry against ipfs probably isn't rocket science and it wouldn't surprise me if that hadn't been done already. Scripts in a browser are just files, so they could come from ipfs. Sessions are often ids or hashes identifying something in a DB. That could be a file in ipfs instead or in a distributed db on top of ipfs. Not saying all of that is a good idea but ipfs can be a bit more than just a file distribution mechanism.