Thank you for the example. Indeed when I saw these kinds of scripts to read three options, that's what made me gag.

That's a *lot* of typing for three options. As I'm sure you know, compared to perl's 3 (three, tres) lines:

use Getopt::Std;
my $o={};
getopts('ab:c:defghijklmnop',$o);

# map { printf "%s %s\n", $_, $o->{$_} } keys %$o;
[download]

I disagree that single letter options are limited, in fact I throw a tantrum about that.
'--min' in one cli app may be '--minimum' in another, we *know* that. So long notation doesn't really improve anything more then legibility, at least for the occasional user. Yes, yes.. then there are monsters like imagemagick convert.. good point, those need long.

The only thing we can ever really be sure of is that hopefully us who code actually reserve -h for help, and that the documentation exists.

The documentation is the authority for an interface. Some basic rules alway, yes.. options before file lists.. -h for help, -v for version, etc.. The user should *never* have to remember anything. Ever. -h, man, and info will tell them whatever they need to know.
By the way, it's not 24, it's 52 or so, caps ! And I use them. And I document them. :-)