It is about being able to think clearly about your code logic. If your code has many places where a variable can change, then it is hard to go back and understand exactly where it changed if you have unexpected behavior. If the variable can never change then the logical backtrace is much shorter.

As Carmack points out, naming the intermediate values aides in debugging. It also helps you write code as you can give a name to every mutation.

But also keep in mind that correct and incorrect is not binary. You might want to pass a fooA to another class that does not want the fooB mutation.

If you just have foo, you end up with situations where a copy should have happened but didn't and then you get unwanted changes.

But that's just it, why would a copy ever happen? Why would you want a correct and an incorrect version of your variable hanging about?

Taking your point of view: you assigned a value1 to a name. Then you assigned a value2 to the same name.

You say that value2 is correct. It logically follows that value1 was incorrect. Why did you assign it then?

The names are free, you can just use a correct name every single time.

Because the account owner withdrew money . The player scored a goal, the month ticked over, the rain started, the car accelerated, a new comment was added to the thread .

The world by definition mutates over time.

Ah, true. If the var is a part of a long-living state, all good. That's just rarely seen in CRUD apps, more common in games.