First of all, it's true that if you're developing a QT4 app and you should definitely consider Phonon when evaluating sound APIs. It exists, it's out there, and if you're linking to QT4 already, there's no reason to avoid it.
That being said, I've always had a bit of trouble understanding Phonon's raison d'être. From what I can tell - and feel free to correct me -, Phonon was made to:
1) have a clear and simple API that meshes well with QT,
2) make portability to Windows and MacOS a bit easier,
3) make sure that QT/KDE libs ensure ABI compatibility - i.e. avoid the risk of having to maintain an old branch of an unfamiliar multimedia framework (f.e. gstreamer 0.8) on their own for the duration of the QT/KDE 4.xx cycle,
4) avoid the politics of having to pick and bless a multimedia framework for use with QT or KDE.
However, I wonder whether in doing so Phonon users lost more than they gained. Not picking an existing framework and creating a abstraction layer means that:
1) Phonon apps can only use the "simplified" API: they can't f.e. manipulate the gstreamer pipeline the Phonon gst backend creates for them
1b) ... which means apps will be tempted to stick to the functionality Phonon provides; brave koolaid-drinking app developers might try to extend the Phonon API (and the backends), others will just pick a multimedia framework that allows them to express what they need for their slightly more advanced app. But of course, they will all choose a different framework ;-)
2) resorting to an abstraction for portability was unnecessary. IIRC, gstreamer can bridge to and reuse Directshow components on Windows, and Quicktime components on MacOSX.
3) they had to write decent Phonon backends which probably is quite a bit of work and deals with the framework they're not familiar with. To avoid _the possibility_ that the framework might move on and stop maintaining the branch QT or KDE committed to for the duration of the ABI cycle. Um...?
4) ... and as mentioned before, while they avoid the politics of having to bless one multimedia system, the discussion won't really go away. The developers of non-trivial apps will still have to make a choice.
End result: if you have some simple and some advanced multimedia apps running, you'll end up with Phonon + backend + one or more multimedia frameworks in memory. I believe that just picking one would've saved a lot of work and memory.