A REMAINDER that would work with a flag-like string would be too powerful, too greedy.

    In [64]: p = argparse.ArgumentParser();
    In [65]: p.add_argument('--foo');
    In [66]: p.add_argument('rest', nargs='...');

If the flag is first, its Action works:

    In [67]: p.parse_args('--foo x a b c'.split())
    Out[67]: Namespace(foo='x', rest=['a', 'b', 'c'])

If there's a non-flag string, REMAINDER grabs everything:

    In [68]: p.parse_args('d --foo x a b c'.split())
    Out[68]: Namespace(foo=None, rest=['d', '--foo', 'x', 'a', 'b', 'c'])

Imagine a REMAINDER could act with '--foo' as the first string.  In[67] would then parse as Out[68] but without the 'd'.  

In documented use 'cmd' acts as a gatekeeper, allowing the REMAINDER to grab the rest.  So does the '--rest' flag in:

     p.add_argument('--rest', nargs='...')

Double dash is another gatekeeper:

    In [69]: p.parse_args('-- --foo x a b c'.split())
    Out[69]: Namespace(foo=None, rest=['--', '--foo', 'x', 'a', 'b', 'c'])

If you don't want such a gatekeeper, why used argparse at all?  Why not use sys.argv[1:] directly?

So some sort of warning about the limitations of REMAINDER would be good.  But the trick is to come up with something that is clear but succinct. The argparse documentation is already daunting to beginners.  

A closed request to document the argparse.PARSER option:
https://bugs.python.org/issue16988

A closed request to document '...'
https://bugs.python.org/issue24647

There was also an issue asking to treat unrecognized flags as plain arguments.  I don't recall the status of that issue.  With that, REMAINDER could grab '--bar a b c', but 'fail' with '--foo a b c'.  It would interesting to test such a variation, but that would be even harder to document.