The two examples given in support of short local variables names rely heavily on convention or prior knowledge. I don't think they're strong arguments for making short variable names.
Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing "i" they would look strange to most people.
Likewise, tmp draws on existing knowledge of /tmp as the location for temporary data on Unix machines.
Also in many early programming languages, variables could be only one or two letters. And in Fortran, the variables i, j, k, l, m, n were implicitly integers and others were real (that itself was as you noted, a carryover from mathematical formula conventions).
Relying on convention is a good thing, as long as your team (and the larger community for that language) is mature enough to have a strong set of relatively easily discoverable conventions.
Strongly agree. Conventions can produce code that is easier to read and to write. Certainly to the uninitiated, most of the formulas in a math or physics textbook look completely opaque. But by following conventions on meaning of symbols, they are precise and expressive and also easier to write.
I'm not saying convention is bad, I don't think that at all. I'm saying that the two examples here aren't good advocates for a general principle of short local variable names. The examples work only because people already know what they mean, due to the pre-existing conventions.
Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing "i" they would look strange to most people.
Likewise, tmp draws on existing knowledge of /tmp as the location for temporary data on Unix machines.