Why the long options?

Short answer - Readability.

Long answer - short answers are for pricks. Nobody really needs a short answer when looking to understand something. When I'm writing a script (or a blog post), chances are somebody is going to (have to) look at it at some point. Whether a devoted reader or an unlucky colleague (or me) two years from now, long switches are like helpful little inline documentation. They make me a bit less pissed at my past self for writing things like this:

###################################################
#     _____    # 
# ^..^     \9  # WARNING - following source code
# (oo)_____/   #           may harm your eyes
#    WW  WW    #
###################################################

Leave better code for "generations" to come

Yeah, let the future me worry about that. So much for professionals.

The one thing that set me off on the path to the long arguments more than anything else was this comic by Randall Munroe:

It has no direct connection to long options and --in-all-honesty - I don't remember the long options of tar while I do remember the short ones. But the point is this:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

... because it will, most probably, be you.

Save yourself a trip to the man page

Consider this piece of code:

roman@u310 ~ $ git config --global core.pager "less -FRSX"

My first reaction was man ls and a rewrite to:

roman@u310 ~ $ git config --global core.pager \
    "less \
    --quit-if-one-screen \
    --RAW-CONTROL-CHARS \
    --chop-long-lines \
    --no-init"

Now, whenever I have to revise my .gitconfig, I can clearly see (or at least I have a faint idea of) what I was trying to achieve.

Don't get me wrong. I am a strong believer in the 80 characters soft limit on line length, but that's what backslashes are for. Escaping is inescapable.

Any code of your own that you haven't looked at for six or more months, might as well have been written by someone else.

Discover new possibilities

Some (although admittedly not many) switches are only available in the long form.

roman@u310 ~ $ alias ls="ls \
    --color=always \
    --time-style=\"+%Y-%m-%d %H:%M:%S\" \
    --human-readable"

In the above example, the switches --color and --time-style are only available in the long form because they are intended to be used in scripts.

Maintain laziness

The short form of the options is for typing the commands on the interactive shell. The long term is for the scripts. Seeing the long form helps you understand what the switch does immediately.

A little more typing now, a lot less typing later.

Laziness is maintained.

Weeks of programming can save you hours of planning.

Readability first

I'll leave you with a quote from the author of the Code Complete. The book that made me look very hard at myself and my approach to programming and life in general.

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer.