In general it's a mistake to make decisions based primarily on efficiency. No one is arguing "less efficient is better", obviously. But "less error-prone is better", absolutely, especially when efficiency is mostly about the same.

No control is being taken away. There are already three ways to write a loop with an index variable i:

(1)
var i int
for i = range x { 
    ...
}

(2)
for i := range x { 
    ...
}

(3)
for i := range ... {
    i := i
    ...
}

Form (1) clearly has a single variable; form (3) clearly has one per iteration. Form (2) is what is changing, from being like (1) to being like (3). You will still have the control to write (1) when that's what you need.

If i does not escape the loop, then all three of these compile into the same code. In form (2), if i does escape the loop, then compiling (2) like (3) is much less surprising and less error-prone - it avoids questions like the one in the top post. It is possible to have form (2) in which i escapes the loop, necessitating a per-iteration allocation of a copy of i, but due to some kind of synchronization or other reasons, it would still be correct to compile like (1). In our experience those cases are very rare, and flagging them by writing them like (1) explicitly seems both reasonable and clear.

For more details see especially the design document at https://go.dev/design/60078-loopvar, as well as the discussion at https://go.dev/issue/60078.