A bluetooth connection has significant latency compared to simple wired headphones or speakers. What's more, the connection latency can vary, depending on the properties of the bluetooth receiver and maybe even radio signal strength as the user moves around.
The interface between an application and PulseAudio can be as simple as "here's some PCM audio data; play this." But it can also be more complicated; something like "Here's some PCM audio data; play this and tell me every 50 ms how far you've got, so that I can tell you to skip ahead if it looks like you're falling out of lip-synch with the video stream I'm playing. Oh, and you'll need to resample it too, since the data has a sample rate your hardware won't directly support." In the latter case, PulseAudio needs to be able to give the application some feedback from the audio device to correctly determine how far the audio data is actually been played at any given time.
As a result, it makes sense for PulseAudio to be fairly deeply involved in Bluetooth audio processing: the more intervening layers there are, the more possibilities for data to be buffered without maintaining accurate feedback, causing lip-synch to be lost.
In fact, before PulseAudio existed, there used to be an ALSA backend for Bluetooth audio, but it was deprecated. I think the problem was that ALSA's interfaces at that time were designed mainly for traditional sound cards, and dealing with a potentially variable audio latency of Bluetooth was difficult.
PulseAudio's interfaces were designed from the ground up to handle various sound devices and even switching audio streams between them while the stream is playing, so it seems to me it has a pretty advanced concept of audio latency built-in too.
Yes, it could have been implemented in BlueZ rather than as a PulseAudio module; but then, BlueZ would have had to present an audio interface for the applications. And since PulseAudio wants to handle "all" the audio on a system (in order to be able to transfer the audio you've currently playing from speakers to Bluetooth or vice versa on-the-fly), it would have to interface with PulseAudio somehow anyway.
Best Answer
Been looking for the same sort of thing for the past few days. With only minor difficulties I was able to build reverb and get it working. I was able to control my laptop's pulseaudio after loading module-native-protocol-tcp. Next step is forwarding port 4713 from my router to my desktop so I can control that too.
The project hasn't been updated in about a year, and doesn't yet allow cookie authentication, so I might have to resurrect it.