Your argument for the superiority of the Web Audio API seems to be 'it's like Core Audio', and you seem to argue that WebGL is great just because it's like OpenGL. What actually supports this argument? Would you be a big fan of WebDirect3D just because it was exactly like Direct3D? After all, virtually all Windows games and many windows desktop apps use Direct3D, so it must be the best. 3D games on Linux use OpenGL so it must be the best. If you're going to argue that it's good to base web APIs on existing native APIs, why not OpenAL -> WebAL, like OpenGL -> WebGL?

Specs need to be evaluated on the merits. The merits for the Web Audio API at time of release:

* Huge

* Poorly-specified (the API originally specified two ways to load sounds, the simplest of which blocked the main thread for the entire decode! very webby. Spec was full of race conditions from day 1 and some of them still aren't fixed.)

* Poorly-tested

* Large, obvious functionality gaps (you can't pause playback of sounds! you can't stitch buffers together! you can't do playback of synthesized audio at rates other than the context rate!)

* Incompatible with existing <audio>-based code (thanks to inventing a new, inferior way for loading audio assets), making all your audio code instantly browser-specific

* Large enough in scope to be difficult to implement from scratch, even given a good specification (which was lacking)

* A set of shiny, interesting DSP/filter chain features, like convolution and delay and HRTF panning and so on, useful for specific applications

* Basic support for playback and mixing roughly on par with that previously offered by <audio>, minus some feature gaps

The merits for the old Mozilla audio data API at the time of Web Audio's release:

* Extends the <audio> element's API to add support for a couple specific features that solve an actual problem

* Narrow scope means that existing audio code remains cross-browser compatible as long as it does not use this specific API

* The specific features are simple enough to trivially implement in other browsers

You keep making insane leaps like 'Web Audio is good because it's like Core Audio' and 'Mozilla wants you to write DSPs in JavaScript because ... ????' even though there's no coherent logic behind them and there's no evidence to actually support these things. A way to synthesize audio in JavaScript does not prevent the introduction of an API for hardware DSP mixing or whatever random oddball feature you want; quite the opposite: it allows you to introduce those new APIs while offering cross-browser compatible polyfills based on the older API. The web platform has been built on incremental improvement and graceful degradation.

P.S. Even if the Web Audio API were not complete horseshit at the point of its introduction, when it was introduced the Chrome team had sat on their asses for multiple versions, shipping a completely broken implementation of <audio> in their browser while other vendors (even Microsoft!) had support that worked well enough for playing sound effects in games. It's no coincidence that web developers were FORCED to adopt Google's new proprietary API when the only alternative was games that crashed tabs and barely made sound at all.