I agree that getting early user feedback is really important, but IMO it would be better if a limited version of Blazor WebAssembly (that would support only subset of .NET features, but have usable runtime size) was released on CoreRT tech and then slowly add more features. Blazor WebAssembly at it's current state, even though it supports all features, is too big to be really usable.
Spreading development resources thin between old tech like Mono and future tech just means future tech will be delayed even more. And when they figure out that in order to get the size down to a competitive levels, it would be better, if some features were kept out of the WebAssembly runtime (eg dropping reflection and relying on code generation instead), it will be too late, because it'll break compatibility with released Blazor WebAssembly projects.
Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.
For context, the Blazor team started with their own interpreter compiled to WASM (via emscripten) instead of using either Mono or CoreRT - because shipping and getting user feedback is really important, and you can't do that while waiting for the ideal tech to be ready. It was swapped out later.
CoreRT is pretty cool tech but I rarely encounter anyone using it. Hopefully that will change in the future. The only CoreRT-based production app I know of is Streets of Rage 4 and it's a very recent release.