C# has very defined behaviour that when "ported" to C++ is going to result in similar speed hits. Allocations are zero'd out. boxing/unboxing objects, array bounds checking.
GC is going to be the big hit as you're still going to need to pay for that even in C++ land. I'm not really seeing what you'd get over just C# with a more modern JIT unless you start converting to non-safe C code and doing sneaky c stuff behind the scenes (and I'm sure absolutely nothing will go wrong*).
The webgl stuff is fine to not be bound (I'm assuming it's being converted to js anyway?) but anything running in the plugin better be.
First and foremost, compiling to C++ means you then optimize it using a full C++ compiler like gcc or clang+LLVM. Not only are those compilers generally better than JITs, they can also do whole-program optimizations. JITs are getting that too (Dalvik=>ART, newer .NET runtimes), but the C and C++ compilers have a big head start.
(In theory a JIT can do all the things C++ compilers do, of course.)
Aside from performance, Mono must be ported to each target platform (I've heard this can take significant effort). On the other hand, well-written C++ code should just run (the rest of the engine is in C++ anyhow).
edit: yes, Unity compiles C# to C++, then to JS to run in the browser.
All true, but you're forgetting that Mono can AOT compile C# to native code using LLVM. That's how Xamarin.iOS works. So il2cpp doesn't really bring anything new to the table.
But it does solve their biggest issue - ultimately enabling Unity projects to publish to the web without plugins (WebGL / javascript).
Once all code in a Unity project eventually ends up as C++ (even if it started as C#), they can leverage Emscripten, asm.js and related technologies to enable Unity devs to use C# in the editor, which is converted to C++, and ultimately Javascript. It seems crazy, but it might just work!
GC is going to be the big hit as you're still going to need to pay for that even in C++ land. I'm not really seeing what you'd get over just C# with a more modern JIT unless you start converting to non-safe C code and doing sneaky c stuff behind the scenes (and I'm sure absolutely nothing will go wrong*).
The webgl stuff is fine to not be bound (I'm assuming it's being converted to js anyway?) but anything running in the plugin better be.