Here’s a good one. How do you create geometry? You’d need a client-side geometry library that can create geometries according to the IFC spec. This is the reason that any infrastructure for dealing with IFC currently processes the IFCs on the server, and spits out glTF, JSON, and other web-friendly stuff. This is a totally reasonable way to handle this problem. IFC stored in STEP files is not designed for transmission over the internet, and deserialization and display in the browser.
Web assembly helps only insofar as you could take existing code written in languages like C++ for working with IFC and compiling it to work in a web client. But I doubt the outcome would be something anyone would be happy with because those code bases were designed for a different time and different use cases. You’d basically be building a desktop application which runs in a browser, which doesn’t take advantage of the benefits of building for the web in the first place. I understand the gist of your question though as wanting, like everyone does, a silver bullet to make bringing IFC to the web easier.
BSI does have a “modernization” project currently under way that takes into account the desire for more of these workflows to be web based. The discussions include modernization proposals for the core IFC schema and the introduction of “tool kits” to provide client and server technologies for transmitting and storing IFC data.
Because Hypar can’t wait around for any of that we’ve built our own pipeline using libraries built with IFC-gen for reading/writing IFC, server-side geometry processing, and serialization to glTF and JSON.