There are several factors that make code containing closures essentially incomprehensible:

1. The closures are all called ClosureN for various N. They could have better names. Instead of Closure123 the name could be e.g. containingFunction_Closure_2. The names would still minify the same.
2. The closures are far from the functions. If they can't be put in the function body at the point of closure creation, they should immediately follow the creating function (or class containing the creating function).
3. Closed names are obfuscated by long access paths (which causes further obfuscation by CSE). See Issue Basic environment analysis: close over values instead of variables if variable is not assigned #4001.
4. Closed names are obfuscated by suffixes. Why this.box_0.first_3 when it could be this.vars.first?
5. Even when the ClosureN names are unavoidable, the essential superclass has a crazy name. The superclass of all closures should be $$.Closure, not $$.Closure176 today and some other number tomorrow.

$$.Closure = {"":
 ["this_0"],
 super: "Closure176",
 $call$0: function() {
  return this.this_0.onLoad$0();
 }
};
...
$$.Closure176 = {"":
 [],
 super: "Object",
 toString$0: function() {
  return 'Closure';
 }
};

I am hoping that real JavaScript functions can be used as closures since then the code could compile to the obvious JavaScript program, using JavaScript's closures. But if that is not possible, the above will still need to be addressed.