I'm fairly certain a collection of tools for working with various media would be much better than the iTunes model. It is clearly the worst Apple software since it tries to fit everything into a one click trojan horse for installing on Windows and yet the mainstream Linux alternatives all cargo-cult the basic interface with no obvious signs they understand why all that functionality is bundled into one program.
Part of the problem is that many people who switched to Linux to get away from Windows don't understand Unix, and tend to expect (and implement!) programs that are based on the Windows GUI model. Unfortunately, it's poorly suited to designing programs in the Unix style. This leads to monolithic GUI programs that will only work if you're already using GNOME / KDE / etc., rather than programs that take advantage of existing the Unix programming infrastructure. (This seems to be less of a problem in the BSD community.)
It's possible to write a separate GUI interface wrapper for programs whose primary interface is a command line or C API, but the Windows programming culture doesn't seem to emphasize keeping them as separate layers the way that Unix does.
Many plan9 programs post a file tree which you can manipulate with regular Unix tools - Acme's are described here - http://man.cat-v.org/plan_9/4/acme
for instance, if I name this shell script C
#!/bin/rc
tags=`{cat /mnt/acme/$winid/tag}
s = `{echo $tags(1) | sed 's/\.c$//'}
8c $s.c && 8l -o $s $s.8
Other similarly behaving programs in the distribution (including the windowing system) are described in http://man.cat-v.org/plan_9/4/
I use Emacs, but my ideal editor would mix Emacs's general buffer and mode extension model with vi-like keybindings, and use Lua as an extension language. Life is too short to write yet another editor, though.
So look around.. you might find something close to what you're looking for.
Thing is, I don't want to add yet another layer on top of either Emacs (!!!) or vim. Both have waaaaay too much cruft as-is. (nvi isn't as bad.) I think the buffers-and-modes extension model in Emacs and vi's modal, primarily single-key interface are good ideas, though, and I don't see any reason why they couldn't be combined. I've also looked at uemacs, vile, and the like, but haven't found one that suits me. In the mean time, Emacs is good enough for me.
But mpd has one crushing flaw: no ratings! I don't know how people live without them.
I'm hoping sometime soon xmms2 will become stable enough to be useful, as it's supposed to have some sort of ratings support, and is build around the same kind of philosophy that mpd and Unix have.
It operates as a OS daemon -- therefore without any UI per se. It is controlled it using a text-based protocol over TCP/IP.
Usually, the user controls it via UI frontend that can be graphical, text-based or what have you. And you can have as many of those as you like (for instance one for xwindow, another for command line, third that shows you what is currently being played, fourth for album art and lyrics...)
If you're looking for a simple GUI audio player, I recommend it, although I'm not really sure how closely it follows this philosophy.
One quick test is if you can see another program using it directly. The reason Unix programs typically have such an austere interface is because it makes it easier to use them from another program (which may be a nice interface).
There seem to be parallel ideas in RESTful web design.
It's not command-line only like most Unix programs, and it's certainly not as simple as most Unix programs, but I do think it does incorporate some of the tenets of Unix philosophy (most importantly: doing one thing and doing it well).
I realize that there's other music playing software that may conform to Unix philosophy more rigidly, but in my experience good back-ends don't necessarily translate to good GUIs, and a GUI is what I want for my media player. I think Decibel is a good compromise.