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.