PulseAudio sucked when it first came out, then gradually grew enough features and stability to make it worthwhile. The people still hating on it are just too boneheaded to appreciate things like your speakers muting themselves when you plug in headphones.
That said, it's still glitchy at times and can't do low latency properly, and JACK1 is inefficient, and JACK2 has a messy threading model, and none of them can do any-to-any latency compensation, so let's hope it all gets replaced by PipeWire and we solve this mess once and for all.
I think you are right. I started using linux about 6 years ago and I have never really had an issue with pulse audio. I have had loads of headaches trying to get JACK working which really shows me how smooth PA is to use.
I've had huge problems with PulseAudio over the last 14 years, but now there are only two left: it randomly hard-hangs a few times a day and it sometimes stops sending audio to a bluetooth speaker (or occasionally to headphones) while acting as if everything is fine. The latter shows up with speakers from two different manufacturers. Everything else I used to hate about Pulse has gotten better: weird audio distortion, clicking & crackling, skipping, messing up the soundcard enough to require reloading modules, getting stuck on mute, jumping to max volume when things were connected - thankfully all gone.
I've had the hang & audio interruption on Mint, openSUSE, an Ubuntu so I'm inclined to think it's something inside Pulse and I've got some hope that those last bits will get fixed. (I am aware that actually playing sound is the first responsibility of a sound system, but I'm being optimistic here.)
Nobody is going to be able to fix that hang unless they know the steps to reproduce. Can you record pulseaudio with rr and capture it happening? Then debugging it should be pretty easy.
I am still wondering if we'll loose all the network capabilities of PA in PipeWire, whereas I don't need its low latency capabilities. Right now, it looks like one will have to install both PA and PW with a bridge between them, which seems a rather bug-prone setup if you ask me.
Does JACK even have enough information to do any-to-any latency compensation? The only "Linux audio" application that I know of that really does this now is Ardour, and it was only in the last few years that it was implemented.
That's the problem, the JACK design does not allow for it. It's why Ardour is still gimped and can't actually do full latency compensation if you connect a track to more than one sink, because Ardour is built on JACK, and JACK can't handle that, and the non-JACK backends for Ardour are kept at feature parity. (You can work around this with sends instead of connecting track outputs, since Ardour handles those outside of JACK)
JACK in general provides latency information throughout the chain, but it does not add delay lines to compensate latency itself, so the problem is that when you connect one thing to more than one other thing, the latency number becomes ambiguous (a range) and you can't compensate for it any more.
That said, it's still glitchy at times and can't do low latency properly, and JACK1 is inefficient, and JACK2 has a messy threading model, and none of them can do any-to-any latency compensation, so let's hope it all gets replaced by PipeWire and we solve this mess once and for all.