Don't let the name fool you. OpenAL is a closed-source library, much like Wwise or FMOD or PortAudio, that just implements playback. Bizarrely enough, it is also the only one of these APIs that uses a similar "play this buffer" approach and suffers from the same issues as Web Audio's memory management, just without a GC.
The actual audio equivalent to OpenGL is OpenSL [0], which I don't think picked up any support from anybody.
PortAudio is MIT-licensed[0] and seems like a decent example of the primitives you need for audio.
Broadly low-level audio APIs are divided into 2 categories:
1. Callback-based - every time the underlying system has a new block of audio available and/or needs to be supplied with a new block, it calls your callback, which reads input data, does whatever processing you want, and writes output data
2. Stream-based - Inputs and Outputs are represented by streams. You can read from the input stream to record and write to the output stream to play back.
Both types of API can be used for low-latency audio, but you generally introduce a buffer of latency when you need to convert between them.
Portaudio lets applications choose which API they want to use.
OpenAL has multiple implementations, including the popular open source OpenAL Soft. They are not all closed source.
OpenAL does have a recording API so it isn't pure playback only.
But you are right in that the OpenAL scope is fairly limited. It was designed for games, particularly for rapid and frequent playback of simultaneous short sound effects. Because of this, the memory management issues you bring up are not often an issue. You load all the buffers you need at the beginning of the level and you keep reusing them without any more memory allocation/deallocation.
OpenSL ES was adopted by Android in 2.3 (API 9). However, they just recently seemed to invent yet another API, and seem to be leaving OpenSL behind.
So are all official OpenGL implementations (MESA isn't official, last I heard). Doesn't stop them from being a standard and being used, although I agree they would be better if they were open source.
OpenGL has to talk to hardware and is implemented by the hardware vendor. OpenAL does not have multiple implementations, isn't provided by hardware vendors and just wraps the platform audio API.
I'm not sure of your point here. Not sure why multiple implementations is a benefit for users. Audio is generic and hardware is cheap enough that the operating systems just implement and include drivers. It's a cross platform library that meets audio needs, including 3D/spatial audio, much like (and designed like) OpenGL.
The actual audio equivalent to OpenGL is OpenSL [0], which I don't think picked up any support from anybody.
[0] https://www.khronos.org/opensles/