I consider the act of executing the logic within a command separate from the act of figuring out if the given command is the one the player is trying to run.

Simple example of why, in a language that probably looks vaguely sensible but isn't exactly C/Cpp/Perl/Java:

look
    format = "~look; ?!at; ?~search(mob@loc)";

    command(client/C, at, mob/M) {
        if(!M) {
            if(at) {
                C.out.print("Look at what?");
                return;
            }

            var/mob/Char = C.getCharacter();
            if(istype(Char.loc, /Room)) {
                var/Room/R = Char.loc;
                R.describe(C);
           }
        } else {
            M.describe(C);
        }
}

The above defines the 'look' command in my MUD. The specifics of what ~, ? and ! do as well as what 'search(mob@loc)' is
isn't really important, although you'll probably be able to guess that the way it works based on the code. Whats really relevant here,
is that the command() function (Which is called by the Parser, if all of the arguments match according to the format) doesn't care where
it gets its information from, and the Parser has already resolved and found the mob the command might need.

Differentiation is important, in my code the functions open( … ) and cmd_open( … ) would be two different things. One is clearly a command and the meaning of the other may be totally unclear.

I would personally like an easy way to have loadable commands that be loaded and unloaded. I.e. they could be simply removed, edited and reloaded if there was a simple enough bug.

Some preliminary parsing prior to determining what command is being used is probably more efficient provided that the basic syntax of things
is identical. Otherwise, it's less useful, I expect.

Many LpMUD's implement verbs as global commands which call methods in the object(s) they are applied to. The command "get sword" would invoke the global verb get, which would parse the arguments as appropriate for that verb, and then call can_get() in every object in the environment until one returns true, or it exhausts the list. If one returns true, it calls do_get() to attempt to perform the command (which might fail). Most verbs fall through to a generic error message if can_get() fails in all objects, but you COULD place generic code in there to do whatever you want.

The advantage is that the parser can be told that get/grab/acquire are all aliai for the "get" verb, and the verb itself can do some argument processing, and then pass the actual workload off to the objects in question (which can either inherit generic getttable behavior, or override it with their own).

Because get (and synonyms) is a global verb, it always has the same syntax and you can minimize the "guess the verb" game that local commands tend to encourage, while still letting your slippery battle axe have special case code for non-dwarves who attempt to pick it up.