If they moved their virtual DOM (the meat of the work React does and its primary bottleneck) over to webassembly, it would almost certainly be faster. I can't really speak to the download size, though I wouldn't be surprised if that improved too.
It's worth keeping in mind that WebAssembly can't access the DOM directly; it has to call into JS in order to do that. I haven't investigated it myself but I'd wager that because of this, any performance benefits would be negligible.
WebAssembly also can't access JS object structures directly, which means that the virtual DOM would have to live in WebAssembly land in the first place, ie. anything generated by JS that you want to end up in the DOM would have to be copied over first, or rather, you want all your VDOM-generating code to be WebAssembly code as well if you want the whole thing to be efficient.
The whole point of a virtual DOM is to simulate and reconcile changes before pushing those changes to the real DOM; it would be fairly clean to do all that processing in wasm and then send the result over to JS for reification.
It's true that there would be some challenges when it comes to "sending" data to the virtual DOM; in particular, event objects could get complicated. I assumed this project has solved that problem, but I didn't read very deeply into it.
Keep in mind that WebAssembly strings are not JavaScript strings, so there is additional data conversion overhead that needs to be accounted for, versus a JavaScript implementation. And it's not just events and DOM updates. If you wanted to preserve React's render API, the input data for re-rendered DOM needs to be converted from JS before doing a diff.
With slower data conversion and faster internal calculation, it's plausible that it might overall be either slower or faster. I don't see any way to know without doing some experiments. It would certainly be more complicated.
It seems like the sort of JavaScript library where WebAssembly would be an easy win would have low API bandwidth (not much data crossing the boundary) and do a lot of expensive internal calculations. As a UI framework, React does some internal calculations but has relatively high API bandwidth.