I don't think it's ever going to be a situation where DOM will go away and canvas will be the only way to do things.

I think there's valuable use-cases for both approaches. I don't work at JB so I'm just guessing here, but I think they have limited resources and had to choose one technology to focus on. For them, I would guess canvas / multiplatform makes sense, because Compose HTML is already working enough that you can do stuff with it even if they never work on it again (there are enough escape hatches you can essentially put anything into the DOM you want even if they don't support it yet). Meanwhile, multiplatform across all targets would let JB and Kotlin compete directly in the Flutter usecase (which, well, I haven't checked recently, but has been very popular for startups).

Having a single codebase that truly works everywhere is very very tantalizing! So I definitely get that.

However, there are still cases where you would prefer targeting the DOM, despite that. For example, SEO is probably a big one. Also, I suspect creating a full screen canvas to render your text blog is a bit overkill (imagine if every webpage on your ultrawide monitor became a 3000x1000 texture). And using Compose / HTML allows you to leverage a whole ecosystem of existing JS libraries which you can integrate into your site.

I think the problem you are trying to solve is the most important thing to consider. If you're a new company and you're just trying to create a rich, interactive app, and you want it to run as wide a range of targets as possible, Compose Multiplatform for Web is for you. If you just want to create a traditional website and you'd rather use Kotlin than JS/TS (or maybe you have a bunch of Kotlin business logic that you can share), Compose HTML is worth considering.

As for the experimental nature of wasm, and its current state of doneness, I can't speak to that. I'm sure someone else can.

FYI there is a #webassembly channel which may be able to answer some of your wasm-specific questions, if you don't get an answer here.

I am not sure about this, so don't quote me on it, but I wonder if someday you can have Compose HTML site (jsTarget) and a wasm part (wasmTarget), and basically embed a Compose Multiplatform for Web component inside scaffolding provided by Compose HTML. (Like how with Android you can mix Compose and their old XML view system). I'd love to hear from someone familiar with Compose Multiplatform for Web if this mental model of mine is totally off base or not.