$ echo “import sys” > quotes.py
$ echo “print(sys.argv)” >> quotes.py
$ python quotes.py -unquoted “-quoted”
['quotes.py', '-unquoted', '-quoted']

In addition, many modern programs allow keyword arguments to be specified after (or even between) positional arguments, but most still recommend listing positional arguments first. In practice, the main one I use in the “wrong” place is the -m/–message argument to svn/git/hg/bzr commit; I was routinely annoyed by a version of Mercurial that enforced the convention. Then there’s `find`…

You’re missing one HUGE distinction in your article, which is doing a disservice to your readers. You introduce this new terminology of “keyword arguments”, but omit the common term “command-line OPTIONS”. (I assume you lifted the “keyword arguments” term from the Python programming world; AFAIK it is absent from the command-line lexicon.) Traditionally, command-line arguments like “-v” or “–help” are called “command-line options”, for the simple reason that they’re optional. The command-line libraries I know (getopt & optparse; haven’t used argparse yet) implement options as just that: optional. It is a CONTRADICTION IN TERMS to have “required options” or “mandatory options”. It is considered bad form (and a misuse of such libraries) to require one or more “keyword arguments” on the command line.

Command-line options may have arguments, e.g. “–output myfile.txt” (those that don’t have argument are, as you write, often called “flags” or “switches”). These are called “option arguments”, and they are usually required by the option. In rare cases option arguments themselves are optional, but that introduces an ambiguity to command-line processing: in “-x one two”, is “one” the argument of the “-x” option, or is it the first positional argument? Best to avoid such ambiguity by having different options for the has-argument and no-argument cases.