Good news to see work being done on the Linux-audio 'bottleneck'. I miss the ease-of-use and options available on other platforms (I left behind).
Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison.
I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions.
Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.
With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem.
As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem.
[1] More specifically: resolving misconfiguration.
[2] By this I mean a solution that works by design, not by luck.
Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.
The main ALSA misconfiguration issue I've personally encountered were not related to the audio drivers per-se, but to codec mixer configuration. It was on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data sheet to work out how to set all the ALSA mixer flags and parameters correctly to get audio routing to send a signal to the output jack.
I never claimed there was a quick fix, but I kinda hoped that Pipewire/Redhat have the leverage to fix whatever needs to be fixed in the ALSA API to make userspace audio a seamless experience.
My naive impression is that the ALSA driver model is "broken"[1] -- most likely because many parts that need to seamlessly work together are atomized into different subsystems with no one organisation held responsible. As you seem to be suggesting, correct operation appears to depend on correct configuration by either the distro and/or the end user.
There should be nothing to configure. The driver architecture should be structured such that it is not possible to ship a "working driver" that then requires individual distro maintainers to intervene for the user to experience "working audio". For example, if the mixer hardware needs to be configured for correct operation, that configuration should be part of the driver or kernel, not some auxiliary file that may or may not be correct in a given distro.
[1] where by "broken" I mean that it incapable of providing the kind of zero configuration plug and play experience that is available on Windows with ASIO, or with CoreAudio.
This can be true for devices following the Intel HDA "specification" (which is still so loosely constructed when it comes to the mixer that it's barely a specification at all). It's also true for many of the USB interfaces out there - the audio/MIDI I/O part works flawlessly on Linux (thanks to iOS' "no driver" requirement), but there's no way to configure the hardware mixer. MOTU went with a web-based configuration process for some of their devices, which is truly lovely since it works on any device with a web browser. But companies like Focusrite (and many more) continue to refuse to openly provide the information required for the ALSA internals to control the hardware mixer on these devices. In some cases, they have been reverse engineered, but often only partially.
Note that the same limitation applies when using those devices on iOS: you cannot configure them fully, unless the manufacturer makes an iOS version of the "device control panel".
So that means that systems like PulseAudio, JACK and PipeWire are where the "seamless experience" are going to happen, not really in ALSA. To use the comparison with CoreAudio, ALSA operates (1) as if every application enables hog mode. Try that sometime on macOS ... and watch your "seamless experience" completely fall apart :)
This is where PipeWire does offer some real hope. Whereas PulseAudio and JACK deliberately target different use cases/workflows, PipeWire seeks to unify them in a similar way to what coreaudiod does on macOS (device sharing, multiple sample rates, buffer sizes, etc. etc.)
Note that there is a cost to this, even on macOS. You cannot get the absolute minimum device latency on macOS, which you can on Linux. But most (all?) users on macOS seem OK with, either because they just don't know that or because they do and think that the convenience tradeoff is worth it. I imagine that if/when PipeWire reaches its full goals, it will impose a similar burden (though perhaps with an option to avoid it by disabling some functionality).
The key point, however, is that applications (2) are going to continue to either the ALSA or the JACK API for doing audio/MIDI I/O. ALSA ... because it's there, and has several 3rd party libraries built on top of it to make things simpler for developers. JACK ... because it's insanely well designed [:))] and gets the job done, portably and efficiently.
(1) well, it mostly does. The library that apps actually use to talk to ALSA can do device sharing, but it's never been widely used for that, and the design is bit ... well, it's not ideal.
(2) all apps except Skype and Firefox, which join the hall of shame for actually deciding to use the "native" PulseAudio API, something the original author of PulseAudio strongly recommended against.