So I must admit, I've pretty much come to accept pulseaudio over the past few years. We've come to a sort of odd truce: it has mostly stopped being a PITA, and I have mostly stopped trying to remove it from my system. Of course, any such cease-fire, where the participants still truly dislike one another, is bound to be a fragile one.
So it came to loggerheads again just recently when I did an all too infrequent "dist-upgrade." Things were kinda bouncy all over the place at first, but over the course of an afternoon I got everything sort of stabilized. But then, at that point, ausio wasn't happening at all.
At first I just killed pulse and moved the binary out of the way so it wouldn't restart (I know there's a better way to do that, but honestly with pulse I'm way beyond caring about being righteous) and of course everything worked fine at that point. If the pulse libraries can't find the daemon, they just try to go directly against alsa. But at some point I discovered that minetest audio wasn't working so I figured I had to dig a little deeper.
It looked like pulse wasn't seeing my audio card (difficult to say for sure because tools like pavucontrol don't give you the alsa names for the devices). A bit of googling and tinkering soon revealed the problem: timidity (also running on the system for some unknown reason) had beaten pulse to the sound card.
So it seems like if you had a fancy newfangled sound daemon that wanted to control every audio device on your system and also a fancy newfangled system control daemon that was introduced ostensibly to deal with dependencies between components, you'd be able to defer initialization of a program like timidity until said sound daemon was up and running, right?