The 50% figure really depends on what you are doing of course. If you iterate through an array and modify ints it can be 30% slower than C++. Other cases it can be 50% or if you use JavaScript’s dynamic typing it can be lower than that.
Dynamic typing in JavaScript can always be avoided though, we even have a #pragma strict which issues compile errors whereever dynamic typing is being used.
The main point is what to compare against though, if you compare against LUA or Mozilla JavaScript etc. They are somewhere between 8-30 times slower than C++.
So the JavaScript / C# provided in Unity is somewhere between 4-15 times faster than scripting languages provided in other engines. The result of that is developers can do practically everything in script code. In other engines, you would be - rightly so - called crazy to do heavy things like mesh deformation each frame, in Unity it’s just fine. Same for heavy AI calculations.
As an example. When we created the terrain engine for Unity 2.0 we wrote it completely in C# at first. All LOD calculations, tree rendering, detail mesh generation, billboarding, rendering, terrain editing tools everything. It was pretty fast, we got ok framerates on 2049*2049 large heightmaps with 30.000 trees. I was actually surprised myself how fast it was running in C#.
In the end we decided to port part of the terrain engine to C++. For us getting the last ounce of performance from the terrain renderer was important. And some areas like generating grass patches surrounding the camera, really benefitted from the speed increase. On the other hand porting the code to C++ took quite a while of course.
Some parts of it are still written in C# and only the parts that really were performance heavy we ported to C++. The terrain editing tools are written completely in C#.
The tradeoff with scripting languages is always one of iteration time and development speed. If i can modify a script while in playmode or even without having to restart the editor in less than 2 seconds. Thats a huge deal, it means i am actually being encouraged to experiment. Thats interesting because it means script code will most likely translate into better game code than if you had written it in C++. Simply because you will try out more things before settling on something. In the case of the terrain engine, we were able to experiment with so many things which we simply wouldn’t have had time for had we written it in C++.
In engine programming this might not be so important but game code is hardly science. There is no one true way of game play. It’s all experimentation. Iteration time is key here and this is where scripting languages rule.
Jit’d script runtimes give you the iteration time and at the same time make you pay very little in performance for it. The other important thing to consider is that the algorithms that are actually taking up performance, like rendering, animation, physics, raycasting are all in highly optimized C++ code. Game code usally takes up somewhere around 20% of the total cpu budget. Thus the 50% loss over C++ for gamecode results only in a 10% overall loss in performance as compared to C++.