Specifically, in that place, there was no need. And prematurely splitting it would have caused us to overthink and over generalize. Having a long, linear and tested function was a better choice.

I understand your point, but perhaps that would have simply been an opportunity to refine your approach to code design. If such a situation leads to excessive deliberation and overgeneralisation, your code base must be riddled with unnecessary overthinking and overgeneralisation.

Or maybe it was just a long, sequential algorithm where breaking it up wouldn't have been an improvement.

I have been programming for more than 30 years. Except for code generated explicitly to be only consumed by machine, I've never come across a function consisting of 2000 lines of code that should not have been broken up. Something is wrong there, and if you show me the code, I'll tell you what's wrong with it.

I can imagine a new control statement with this type of syntax:

  code
  code
  uses (a, b, c, d) {
    code
    code
  }
  more code
  more code

It's a block that defines the variables it uses, with no other access to the outer scope. It would help break up a linear function into blocks with clearer dependencies.

Glad you can see that without even looking at the code.

Some things you don't have to see to know whats going on. Function with 2000 lines of code? Have fun rationalising this.