[lucb1e]

Exceptions exist, sure. The title is that you prefer single letters generally but the submission text is more about exception situations for throwaway variables, so it doesn't quite sound consistent. The title and submission text also contain no concrete question, so I'm not really sure what you're looking for here.

Even in your example cases, though, compare these two lines:

   a = arr.filter(n => n.flag === true);
   a = arr.filter(user => user.flag === true);

Which one is more clear here?

I hate ${JavaStyleVariableName}s that are so long that it takes extra mental effort to parse the names, so I'm fully with you if you argue for appropriate variable name lengths, but having any name at all (one character is typically not a name) can give some indication of what it is, even if abbreviated or otherwise terse. The variable 'n' sounds like a number, rather than an object that would have a .flag property. While not very confusing, it's also not the most intuitive thing to call it. I wouldn't flag this as "please fix" in a code review, but it's also not better than using any name at all.

[cirrus3]

Using "n" here instead of "user" just screams lazy... I wouldn't flag it either, and it will probably never be a problem is this case, but I would momentarily think of the dev that wrote "n" as lazy and worry a tiny bit more about what other code they are writing lazily as well. Don't be that person.

[sublinear]

I completely agree.

One letter names are a code smell I associate with the nastiest bugs I've experienced especially when the git blame shows multiple authors on it.

[AndrewDucker]

At the very least make "n" "u", so that it's easier to remember it's a user!

[techsin101]

Sure, in this example user looks better. But as I said this code is not going to be existing on its own. There's going to be code preceded by this. Which is going to give a pretty good idea of what is being filtered on and you can always have comments before the code that can explain the general idea of what you're trying to achieve instead of burdening short-lived variables with a role of needing to give hints of what's going on at the expense of readability and speed of parsing mentally