Disclamer: I touched kernel driver development only for tiny TRNG driver for Rockchip SoC, but I mostly write user-space applications and did not touch audio directly as developer(only through OpenAL-soft).

Fewer kernel calls between hardware and software for loerw latency processing of audio is a must, there is a minimum amount of latency you can have with audio for anyone performing and that's debated by a total round trip time frame.

My eyes!

1. There are no "kernel calls between hardware and software" normally. Well, Intel graphics drivers have execution requests, but that is definetly not what you wanted to say.
2. Maybe you wanted to say fewer system calls? In that case I am sorry to disappoint you, but ALSA documentation states it has mapped ringbuffers, so it's already "zero" syscalls(preemption will still happen, but it is possible to make no context switches on multi-core system).
3. Maybe you wanted to say fewer register updates? In that case the only solution is to make better drivers and better hardware.
4. ALSA has much less latency than IPC-based APIs like JACK or Pulse.

Trouble is to do most anything with digital audio you require a buffer (here we add more latency) so that we can do the things we need to.

Correct, audiocards don't implement raw dac access because it is jittery shit.

Your audio device will have it's own buffer (and in the case of ALSA and Linux) your operating system will implement what's considered an audio "server" which will add is own buffer to route to whatever you are thinking you need to do and blah blah so on so forth.

And here you are mixing everything together to the point of being incorrect. ALSA is not audio server, it is audio userpace-to-driver api. You can opt for using audio server and you can opt to make alsa application to go through 11 out of 9 ring of hell to use audio server. There are two buffer at this point: one on your audio card(and you can do nothing about it) and one(or multiple "parallel" if mixing is enabled) in ALSA driver.

HAL drivers

Please stop adding more and more abstraction layers.

like ASIO

Ah, monopolistic(exclusive) mode. So many people complained about mixing being disabled by default, now people complain of it being enabled by default. I want to make a joke about OSS(deprecated API back in 90-ies).

mean you have much higher stability

ALSA is as stable as it gets. If your software is unable to keep-up with updates, then write software better.

and much lower latency as you now have fewer buffers which is less added latency, fewer interruptus to deal with,

So less latency or less interrupts? To reduce amount of interrupts you need to increase size of buffer and latency. Opposite is also true. You cannot say C and D both are less then A and B in A*B=C*D. At least using regular algebra.

If you want to learn more consider first learning what ALSA is or any of the terms I originally used. I suggested starting with the wiki page where all of this is already explained

Now I really want to know what you know about ALSA because it seems you don't know it well even as a user.

Funfact: you can force any application using ALSA to exclusive mode. Expect exclusive mode side-effects: no sound from other applications.

I suspect they meant “Hardware Abstraction Layer” for “HAL”

https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

After application transfers the data in the memory areas, then it must be acknowledged the end of transfer via snd_pcm_mmap_commit() function to allow the ALSA library update the pointers to ring buffer. This kind of communication is also called "zero-copy", because the device does not require to copy the samples from application to another place in system memory.

When you tell RTFM expect to see manual stating opposite of your point.