An important rule is missing here: variables should be named with their scope in mind. So if a variable is longer lived and has larger scope its name should be that much more descriptive because when you're looking at it the only thing that will tie the value of the variable to the context within which it can be used is its name.

So 'i' is fine for a loop control variable with a scope of five lines but totally inadequate for something expressing a larger and longer lived concept.

Ditto for function names and parameters to functions, if the function and the parameters are named properly understanding the function is trivial.

So if you write a chunk of code that exports one or more functions that is where your effort should go, that's the public interface. The reduced scope of the rest of the code should make any naming issues much more limited.

This is also why it is good to assign one person on a team to defining the interfaces between the code. That way you get consistency in naming which is a great thing to have in a codebase.

Anecdote time:

I once worked for a game programming company. One of the programmers there would name all his functions and variables for fruit and vegetables. It was his way of ensuring job security. Guess who got saddled with untangling the salad when he left the company.

cucumber(cherry, strawberry, orange);

Good luck with that...