Honestly I don't know why the author didn't go with the client/server model. Running a music player as a daemon and having a client that connects is awesome, and allows things like remote control (android apps, etc) to happen much more easily.
MusicPlayer is already highly modular. Adding a server interface listening on some TCP port is trivial at this point. Full control via an IPython shell or just the console is already possible. (In the beginning, while it didn't had any GUI, the IPython shell interface was how I used it.) There is nothing really complicated in developing some remote control.
The way MusicPlayer manages the queue, i.e. the intelligent automatic main queue is not trivial/straight-forward to emulate in MPD and it would be hacky - that is the first and main reason I didn't used MPD. Then, using MPD wouldn't really have made it simpler, only more complicated. Forking MPD itself and extending/changing it in the way I intended would maybe have been a solution but I thought it would be simpler to just code the player engine from scratch. Despite that, MPD does not support many of the current features of MusicPlayer, like the builtin loudness analyzing algorithm, etc.
In fact, why they didn't just use MPD escapes me.