A loaded question - "excessively" implies you think it's wrong. Of course you can obscure meaning by using non-descriptive names, but I use a lot of one-letter identifiers if the context is enough to easily interpret them.
For example, all http handlers in Go are the form of:
type HandlerFunc func(ResponseWriter, *Request)
And when you code such a function the arguments are normally named "w" and "req", ("writer", "request"). To give them longer names would be wasteful, as their types already tell you all that you need to know. (I think the reason you don't just call it "r" is to prevent confusion with a "reader"/"response".) Furthermore, this idiom is so widely applied that it reduces your cognitive load considerably (naming things is hard!). When the type already expresses the purpose, don't bother thinking of a good name.
I saw a similar philosophy at work in a dynamically typed language (Lua):
function foo(String, Float)
-- Some code
end
"String" and "Float" aren't type names. "string" and "float" are. But they are just as effective at signalling intent, when the name of the type is enough.
It's also pretty easy to have a one-letter convention for type-obvious situations. For example, if I name a variable s, f, i, or n, then I always know that it's a string, float, integer or integer, respectively. Beyond type information, I also always know that "n" is going convey the notion of a count.
Obviously again this is only reasonable if you only need to know type information, but if you're writing a function like
repeatString = (s, n) -> (s for i in [0...n]).join ''
then it's completely pointless to give those more verbose names. You wouldn't actually be conveying additional information until you got to an utterly ridiculous point like
repeatString = (stringThatWillBeRepeated, numberOfTimesToRepeatTheString) -> (stringThatWillBeRepeated for i in [0...numberOfTimesToRepeatTheString]).join ''
For example, all http handlers in Go are the form of:
And when you code such a function the arguments are normally named "w" and "req", ("writer", "request"). To give them longer names would be wasteful, as their types already tell you all that you need to know. (I think the reason you don't just call it "r" is to prevent confusion with a "reader"/"response".) Furthermore, this idiom is so widely applied that it reduces your cognitive load considerably (naming things is hard!). When the type already expresses the purpose, don't bother thinking of a good name.