I have many examples from my day job. (Optical Crossconnect Business, Alcatel-Lucent, probably
sounds familiar :-)

Here is one where multi-methods would be ideal:

(I am using the dylan syntax for the sketch)

//-----------------------------

define class <synchronous>(<object>)
end;

/*
define class <plesio>(<object>)
end;

... other transmission methodologies
*/

define class <tributary>(<object>)
  slot matrix-ref :: <integer>;
end;

define class <wrapped-ethernet>(<tributary>)
end;

define class <synchronous-tributary>(<tributary>, <synchronous>)
end;

define class <SDH-tributary>(<synchronous-tributary>)
end;

define class <SONET-tributary>(<synchronous-tributary>)
end;


define generic crossconnect(from :: <tributary>, to :: <tributary>) => ();

// (1)
define method crossconnect(from :: <tributary>, to :: <tributary>) => ();
  matrix-connect(from.matrix-ref, to.matrix-ref);
end;

// (2)
define method crossconnect(from :: <synchronous-tributary>, to :: <tributary>) => ();
  next-method();
  enable-external-fault-monitor(from);
end;

// (3)
define method crossconnect(from :: <synchronous-tributary>, to :: <wrapped-ethernet>) => ();
  next-method();
  enable-extra-bandwidth(to);
end;

//-----------------------------

In our system we have a dozen of transmission types, so the combination
of input->output becomes huge. Currently all processing is done in
various huge functions with many "if" clauses that check for the various
specializations. It is a mess. Using multi-methods would be a big leap
in maintainability.

What I have shown above is the binary dispatch case, but usually there are
some more arguments which also guide the behaviour and are best included in
the dispatch scheme. Dispatching over 3-4 arguments is not uncommon, and such
a situation would definitely break any visitor-like pattern.

The only thing one has to be careful with is the ambiguity of the method resolution
(Dylan resolves in a symmetric way (for arguments) but respects the left-to-right
order of class inheritance (when multiply-inherited).) A good compiler warns the
user if ambiguities can lead to surprising method selection.

Another nice example to multimethods is when a state machine is triggered in different
situations. For example a circuit can be completed by the local segment or by a
remote segment, and whether this segment is the dropping segment of the circuit:

//-----------------------------

define generic completed-by (state :: <state>, situation :: <segment>);

//-----------------------------

here we typically have 6-8 states and 8 situations ({local, remote} x {add, thru-out, thru-in, drop}).