I think a good rule of thumb is: The length of an identifier should be proportional to the size of the scope in which it is valid.

As an example: If you design an API, names like "openBinaryFile", "handleValidationError", "primaryDrawingContext" are a good idea. If you have a simple 1-line or 2-line helper function, one-letter names can make things vastly more readable, because you can see the "meat" of the code more easily without drowning in 20-letter identifiers spilled over 5 lines. So just using "ctx" or even "c" for "primaryDrawingContext" in a one-liner can improve things. This is even more true when you have a type annotation with long, descriptive type names for this function.

But all of this is very subjective, and in the end writing good, readable code is a bit of an art. There are guidelines and tips on how to do this, but there can never be hard and fast rules which will make everybody happy.