I think the amount of polymorphic code Haskell enables means that single-letter variables are more common than in other languages (where they're usually confined to narrow scopes), and there's a lot less to say about them. Another HN commenter on this post mentioned IEnumerable<T>, which is very similar: you know nothing about T, but you need to call it _something_, and there's a common understanding in the community that you call such type variables <T>.
Haskell's typeclasses then mean you've got a lot of different concepts that could show up in a type signature, but they're still polymorphic and there's not much you _can_ say beyond "this is Foldable", or "this is a Monad". So an even broader convention has emerged.
You know that it's the type you enumerate over. I'd agree that in this case, <T> is sufficiently common language that people understand the reference (similar to how i is understood to be the index counter in a for loop), but you could definitely use a more expressive type name [1]. This becomes important if your type has two or three generic parameters.
[1] You might argue that this is more typing overhead, but your tooling will easily auto-complete it for you or refactor it after you've written the code, but before committing it. And if you don't have that type of tooling, you're in need of expressive variable names.
The author says as much. There's overlap for sure, but all the monad stuff, for one, is mostly Haskell-(or functional language rather)-specific.
My errors are caught as ‘e’, files are ‘f’, apparently indices are i, j, k, for as long as people been writing C.
K/V are keys and values, and, well, ‘t’ is time. I’m sure you can guess all other…
I really don’t understand how is this a specific language’s thing.