I think it does, but it is hard to track the initiatives that tackle this. That's why I'm asking.
The DOM has been designed as a JS API (for better or worse), accessing that from WASM will always require to go through some FFI layer (this layer may be hidden and automatically created at runtime, but it still needs to exist).
The question is just how much marshalling needs to happen in that FFI layer. Making the DOM (or other Web APIs) actually WASM friendly would require an alternative DOM API which looks more like a very low-level C API - e.g. not using Javascript objects/strings at all, but only numbers, some of them 'pointers' into an ArrayBuffer (e.g. the WASM heap).
There's also a middle-way of adding such 'garbage free' functions to web APIs which allow to be called with less overhead in the JS engine, for instance WebGPU has such functions, and they were specifically added to reduce marshalling and GC overhead when called from WASM.
E.g. GC-free Web APIs would be much more useful than GC support in WASM for interacting with the browser side. GC support in WASM is mainly useful for languages that depend on garbage collection, because those can delegate the GC runtime tasks to the JS engine's garbage collector.
"The DOM has been designed as a JS API (for better or worse), accessing that from WASM will always require to go through some FFI layer (this layer may be hidden and automatically created at runtime, but it still needs to exist)."
I don't see that. The DOM is the underlying data structure and what we need is direct access to it form WASM, without FFI or going through JS. WASM should be a first class citizen next to JS.
Also if we're talking big changes like this it would actually make more sense to implement the DOM on top of the 3D APIs, and not the 3D APIs as an appendix of the DOM ;)
My understanding is that it originated as a straight binding to Netscape Navigator's C++ API, so it's actually originally a C++ API.