What are the static functions that would be hard to unit test?
Are you talking about Dispatcher::instance() as the default value for the constructor arguments?
First, it's perfectly possible to unit test the static function itself.
Second, it's perfectly possible to pass something non-static to those constructors instead.

When it comes to coupling, there is a real difference between coupling in interface, and coupling in implementation. Coupling in interface is necessary and desired for any computer system; interfaces is how different parts can talk to each other without being physically coupled.

It sounds to me as if you've read the GoF book recently, and are a little too emotionally attached to the nomenclature they present. When the book was new, and I read it, the reaction I had was "great, now the industry will have agreed-on names for all the things we've been doing all along." However, what I've found over the years, is that any programmer who does not already have a lot of experience when reading the book, should be kept away from writing code for six months after reading the book, because it tends to have too much influence (in the sense of "if I have a hammer, everything is a nail").

A good book to describe the difference between interface coupling and physical coupling is Lakos "Large-scale C++ Software Design." Again, it describes a lot of practices that most people have already been doing for years, but it's a good text on practices in software design that are necessary, but not necessarily taught in school. And what I call "interface coupling," I think he calls "dependency injection" or "dependency inversion," so there's still a bit of nomenclature problem...

That being said, having a central function that dispatches AND handles all messages isn't going to work well, because that function would need to be physically coupled to all objects (handling == physical coupling). However, having a central manager that maps from object ID to handler, or perhaps object ID and action ID to handler, is common and expected -- and eminently unit testable, because you can configure it with dummy inputs, dummy outputs, and make sure that the right outputs get called when you push pre-determined inputs into it.

At the lowest level, game packets typically look something like:

FRAMING (packet id, sequence number, timing, authentication, etc)LIST-OF  TARGET-OBJECT  ACTION  PARAMETERS

By necessity, the representation of TARGET-OBJECT needs to be globally understood by the networking system. That's where dispatch happens. The target-object could then, separately, dispatch ACTION, and interpret PARAMETERS in the context of that ACTION. However, it would be just as reasonable to make the format (but not necessarily semantics) of ACTION be globally understood, and part of the top-level dispatch. That neither increases nor reduces coupling; it just formulates the necessary work in a different way.

In the first case, there would be one known interface from network to object, where the object of the given ID would receive notification of the packet. Each object would then have to dispatch ACTION, which generally is class dependent. This means that the action dispatching is replicated in each class, which isn't necessarily great design -- it allows different objects to dispatch actions differently, which may confuse future attempts to change or optimize the protocol. On the other hand, registering each action for each object may mean more traffic to the global registry when new objects are created, and old objects removed, which may or may not be a performance problem. My feeling is that it won't be a performance problem, because creating/destroying objects is limited by network bandwidth, and thus can't be that frequent.