So I looked in to this, and it turned out to be a really interesting/difficult issue. Part of the problem is the engine is so well optimised! Benchmarks like quadissueperf are so efficient that they are not bottlenecked on executing instructions - instead they are limited only by memory bandwidth. Therefore they cannot be optimised - or made slower - by changing the code: only the memory layout will affect it.
In r150 we simply added a small new class for the instance's script interface for the scripting feature. Despite being small it used a bit more memory per instance, therefore requiring more memory bandwidth, therefore reducing the benchmark score. In r152 we made the class a little bit bigger, which made the problem worse. We've already seen the same thing happen in the past if you add a behavior or family to the object in the performance test - it takes a bit more memory to store that family or behavior, and the benchmark score drops a little as a result. It's really hard to avoid this.
The good news is there are things we can do: mainly just making sure features that are not used do not allocate memory. Simply lazy-loading the script interface seems to solve this, since it means it doesn't use any memory at all unless you actually access it from script. We can also go further and make sure things like instance variables, behaviors and effects do not allocate memory unless they are actually used.
So this should now be resolved in the next release - and hopefully we can go a little further in the next release or two after that, as there are more internal details that can be tweaked the same way.