Trust me on this: if you organize your code the way revdiablo suggested, no one will have trouble understanding what's going on. People who are still somewhat new to perl will most likely learn a lot from looking at such code, but I don't think they'll have trouble understanding it. You could actually put the "%commands" declaration (with all the sub definitions) in a separate source file, and just "require" that file in your main script -- on the whole, if you can "objectify" and "modularize" your scripting, you'll be better off (and so will anyone who inherits the code from you).

As for defining the CLI grammar, you could simplify things a lot by sticking with single-word commands; e.g.:

 time    # with no args, command means "show time"
 time arg [...]   # with args, it means "set time"
[download]

and so on. By writing the command handler functions to work this way, you'll need fewer distinct commands, which will be nice for everybody involved. So it could look like this:

while (<STDIN>) {
    my ( $cmd, @args ) = split;
    if ( exists( $command{$cmd} )) {
        $command{$cmd}->( @args );
    else {
        $command{default}->();
    }
}
[download]

One more suggestion: you might look into Term::Readline, to enable various nifty unix-shell-like behaviors (command line editing, command history and recall, tab completion of commands and file names, etc).

Update: forgot to suggest how some functions might be written:

my %command = (
    time => sub {
        if ( @_ == 0 ) {
            print "time is ", scalar localtime, $/;
        } else {
            print "let's pretend the time is @_\n";
        }
      },
    date => sub {
        if ( @_ == 0 ) {
            print "You don't have a date for tonight\n";
        } else {
            print "Okay, we'll see if @_ will go out with you\n";
        }
      },
#  ... and so on (updated to remove undeclared array)
);
[download]