This is completely true. I just want to add that the problem with currently standard WebAudio is that the audio callback still goes into the main js context/thread, so any custom callbacks via ScriptProcessorNode can be pre-empted by pretty much anything. That means that the target latency is the upper time bound for any js callback or work unit, and it gets really iffy when you approach real-ish time (10ms or so).

The next attempt is AudioWorklet, which runs in a separate js context and on the audio thread. Sadly still exclusively in Chrome, so I can't be bothered to invest heavily in it.