Sure an automatically generated JS shim which marshalls between a web API and the WASM module interface is possible, but that's still not direct DOM access, it still goes through a JS shim. The detail that this JS shim was automatically generated from an IDL instead of manually written is really not that important when the question is "does WASM allow direct DOM access", the simple answer is "no".
The underlying problem is that you need to translate between a Javascript-idiomatic API and whatever is an idiomatic API in the language you compile into WASM, and idiomatic C, C++, Rust, ... APIs all look very different so there isn't a single answer. It's not WASM being relevant here, but the high level source language that's compiled into WASM, and how well the DOM JS API (and the Javascript concept it is built on) map to APIs for various 'authoring languages'.
The whole problem is really quite similar to connecting two higher level languages (e.g. Rust and C++) through a C API (since this is the common interface that both Rust and C++ can talk to - but that doesn't mean that you can simply send a Rust String to the C++ side and expect that you automatically get a std::string - this sort of magic needs to be explicitly implemented in a shim layer sitting between the two worlds) - and to use the string example, there is no such thing as a WASM string, instead how string data is represented on the WASM side depends on the source language that's compiled to WASM.
If you push the shim to JavaScript then it isn't direct DOM access. But you could push the shim into the C++ browser code, providing one DOM API to JavaScript and slightly smaller shimmed version to WASM. Then you cut out the JavaScript middle-man and can call it "direct DOM access".
Of course you couldn't provide idiomatic versions for every language, but the JS shims also can't really do that. Providing something close to idiomatic C would be a huge step up, the language libraries can then either offer a C-like API or choose to build new abstractions on top of it
> But you could push the shim into the C++ browser code
That's easier said than done because of details like that you can't build a JS string on the C++ side, the translation from string data on the WASM heap into a JS object needs to happen on the JS side.
But this is how all the Emscripten web API shims work, and they do this quite efficiently, and some of those shims also split their work between the JS and C/C++ side.
So to the programmer it does look like with Emscripten there's direct access to the (for instance) WebGL or WebGPU APIs, but in reality there's still quite a bit of JS code involved for each call (which isn't a problem really as long as no expensive marshalling needs to happen in such a call, since the call overhead from WASM into JS alone is really minimal).
The underlying problem is that you need to translate between a Javascript-idiomatic API and whatever is an idiomatic API in the language you compile into WASM, and idiomatic C, C++, Rust, ... APIs all look very different so there isn't a single answer. It's not WASM being relevant here, but the high level source language that's compiled into WASM, and how well the DOM JS API (and the Javascript concept it is built on) map to APIs for various 'authoring languages'.
The whole problem is really quite similar to connecting two higher level languages (e.g. Rust and C++) through a C API (since this is the common interface that both Rust and C++ can talk to - but that doesn't mean that you can simply send a Rust String to the C++ side and expect that you automatically get a std::string - this sort of magic needs to be explicitly implemented in a shim layer sitting between the two worlds) - and to use the string example, there is no such thing as a WASM string, instead how string data is represented on the WASM side depends on the source language that's compiled to WASM.