It's a terrific API. Manual resource management is "strongly recommended", because you can't trust the ECMAScript implementation's garbage collector to reclaim resources promptly. (Well, no. It's a garbage collector.) So, lacking proper RAII or some other structured resource management, we'll have all sorts of crap apps leaking scarce resources.
Asynchronous design with callbacks is "strongly recommended" to avoid blocking the implementation's main (generally only) thread. That's fine; no programmers who work on toy applications ever have trouble with asynchronous design.
A zillion magic constants, defined as integers. No type safety. (And yes, you can impose some run-time type validation in ECMAScript; you just have to do it yourself. A WebCL implementation could have, if the API accommodated it.)
WebCLDevice.getInfo is great for fingerprinting a victim's machine.
"WebCL has been designed with security as a primary concern." Oh, well, that's all right then. What hath this "primary concern" yielded? Memory access protection, no object reuse, and a recommendation that the underlying OpenCL implementation guard against runaway apps. Groundbreaking.
They did leave out a lot of the more-dangerous OpenCL features, so that's something. But not nearly enough for me to trust WebCL - not that I can imagine having any need, or indeed use, for it anytime soon.
An aside: I noted the following hilariously vile phrasing from the Wikipedia article on WebCL: "WebCL allows web applications to actualize speed with multi-core CPUs and GPUs". At last, my web applications can actualize themselves some speed! "Man, this trip is taking forever. Can't this car actualize any more speed?"