Speaking as a PA developer, I'd be interested to know why you say that.

Because it is true.
There is no actual signal processing done by PA, it is all offloaded to FFMPEG (or whatever it is now).
The proper way to do it would be to make a FIR filter yourself. As that way you can do re-sampling in the same step as changing the volume and even do a low-pass high-pass filter (aka graphical equalizer), all for free.
(idk if the stereo to 2.1 thing is done by PA, i stopped looking a long time ago)
It's all in floats, that is the recommended thing by the audio community but is not needed when there is only one filter to be applied to a signal, instead of fixed point. So there are two conversions that can be skipped.

The only assembly optimization in the whole of PA is the float to int (and back, maybe, idk) conversion.

The server is.. it should only be system-wide. And i know you all yell "security" and such, but there is no security concern when it comes to circular buffers plus synchronization message way of streaming data.
While at streaming data, the "new" PA thing is using memfds to send PCM. There is no reason specified as to why, and i can't think of anything it would improve (no, it's not security).

The server is also a complete mess in terms of how it handles streams. (from the timing algorithm to handling errors like the bluetooth dropping one mentioned in this thread)

Are you going to just say "you are wrong" now ?

No, it is not. If it works, it's because of the dmix plugin (which has other issues, such as waking up your CPU >50 times a second. Not exactly desirable on a laptop).

First time i hear of it. And if it is so it is either dmix-s fault or whoever wrote the .asoundrc didn't close all audio device using processes. (or there is another user playing something using different settings)
If you don't do anything special, it will never fail. (ALSA has been used for decades, and still is)