It took a decade to get the JavaScript cruft and layers of browser features that basically makes the modern browser a native gaming-like app with a gigantic scripting engine and a fat pipe internet connection.
It's possible iterations on IPFS could parallel the current web. But I am not a fortune teller. I just wanted to be sure we all understand where the web came from: serving files as if a gigantic connected filesystem.
That being said, FTP though.
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.
The article bills it as some alternative to HTTP, but it's a subset of functionality. You can't do dynamic pages with IPFS. There's no concept of cookies, so stateful sessions aren't a thing.
Why do articles insist on comparing IPFS to "the web", whatever that means? It's a distributed filesystem. Not at all representative of most content on "the web".