Some communities actually promote that style. Particularly the terse array languages like APL or K/Q. Each file might only be half a page of code (you can do a lot with a single line of APL) so long and detailed names might not be necessary. You can look at all of Aaron Hsu's talks to get a better idea of this (particularly everything about his co-dfns compiler). He wrote thousands of pages of code to finally get to the final compiler that is a single page of code (fits on a t-shirt).
It makes no sense to me. Even in math notation where one-letter names and terse notation are the norm, you rely heavily on familiarity and convention to understand the notation.
Reading a computer program written in such terse style is like reading a textbook in a completely unfamiliar field, without a symbol glossary or explanatory text. The cognitive burden can be extreme.
I do agree that there is some value in higher information density and the ability to quickly "pattern match" on sections of code (eg. regex), but only up to a point.
Looking at the scripts, they're mostly wrappers intended to be called on the file or a selection, so closer to a macro, shortcut, vim mapping etc. instead of a general purpose executable name. So closer to "C-x C-k" than "M-x save-buffers-kill-terminal".
(Most of them seem to have parameters, so it wouldn't make sense to golf this even further and have a exec command that just accepts one letter)
It's because they're easy for me to remember and easy for me to type. No other reason. a=awk, c=git commit, g=go, r=replace, s=sed and u=undo (obviously z would work just as well for undo). The core idea was commands in the editor is just any executable in your system instead of a custom scripting language - kind of like CGI. You are free to implement commands in bash, tcl, javascript etc.
