The obvious thing to do is if you need maximum performance, write the loop itself in JavaScript, and avoid mixing interfaces (in this case event blocks and JS). So why not just do that?
I did that too, which I mentioned and is in the project, to compare and point out that was blazing fast. The TLDR was don't use JS blocks inside of big eventsheet loops, or eventsheet blocks that will get called alot, which I had been doing in my project and wondering why it was so slow.
The reason you can't write the loop in JS is because you might be doing other things in that loop that you can't handle with JS, or should by recommendation of the SDK manual.
But this isn't expressed in the manual, and everybody is like "Performance problems?" write a JS module or script. But it turns out this doesn't solve the issue at all, but makes it worse.
Thus the only solution is AddonBehavior with sdk (tedious and laborious to write) or built in event sheet functions, but they have the overhead too.
Which, leads me back to the issue about the insanity of manually in-lining construct functions in order to improve performance. Which is BAD for scalability, maintainability and general mental well being lol.