User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Visit https://stackoverflow.com/a/40070682/15842368
Run the first code snippet.
Click "Start"
Wait for the result.

Actual results:

Firefox 94.0b9:
Average time with var: 155.41ms
Average time with let: 147.82ms

Edge 95.0.1020.30beta:
Average time with var: 37.52ms
Average time with let: 36.88ms

Expected results:

The result shows Firefox is too slow in its JavaScript engine. It shouldn't make such a big difference.

The test case can be reduced to:

function test() {
  var x = 0;
  for (var i = 0; i < 50_000_000; i++) {
    x += i;
  }
  return x;
}

for (let i = 0; i < 4; i++) {
  let start = dateNow();
  test();
  let end = dateNow();
  print(end - start);
}

Eventually x += i overflows the Int32 range and we bailout, but keep the Ion code (!). After computing x += i in Baseline, we handle the JSOp::LoopHead and because the Ion code is still present, we directly jump back into Ion. The Ion code has an OSR entry which unboxes OSR values to Int32, which will fail because the OSR value for x is now a Double. That leads to setting the SpeculativePhiBailout flag and we no longer unbox OSR values. All the extra overhead in this µ-benchmark is then caused by extra boxing and unboxing overhead.

Glad to here you experts have found the root cause. Though I don't really understand that, I hope the bug could be fixed soon.