Runtime size can be an issue; though arguably WASM is going to outperform minified javascript probably for the same code.
Typical SPAs only manage to stay small by simply not using a lot of run-time dependencies. The same trick will work with wasm. If you don't need it, don't depend on it. Simple. Or alternatively, trade off not having to reinvent the wheel against a few MB of dependencies. In an age where people watch 4K youtube videos, pulling in a few MB is not that big of a deal anymore.
And incidentally, the lack of any sizable run-time dependencies also makes replacing those not that big of a deal. E.g. most of the React ecosystem involves a lot of compile time dependencies (hundreds of MB typically) but not a whole lot of run-time dependencies that people actually ship with their applications. A few hundred kilo bytes typically. I've used alternatives for React that only measured a few thousand lines of code. There's not a whole lot that those run-time libraries actually do that is that essential.
I've noticed with Kotlin js that there isn't a whole lot that I need or miss. Actually, even just having the Kotlin standard library is already a big upgrade relative to what browsers and Javascript have without any dependencies added. Add co-routines to the mix and few other multi platform libraries (e.g. kotlinx.serialization, kotlinx.datetime, ktor client) and it starts feeling like any other modern Kotlin stack that I've worked with. Except it all works in a browser. Is there a size penalty. Yes. Does it matter that much. Not really.
Yes it adds up to the runtime size, still most implementations can be eventually trimmed down to similar sizes of typical SPAs.