There are plenty of zero-cost C++ wrappers available, including the official bindings. Most people who use OpenCL from C++ tend to accumulate their own convenience wrappers over time. The rest of those languages have fairly easy interoperability with C code and therefore access to the C api, though some may also have established convenience libraries. I wouldn't suggest .NET or Haskell for most serious GPGPU work, but Python, Julia, Fortran and others are frequently used. The PyOpenCL library is particularly excellent.

If you were referring to the kernel language (a restricted subset of C99), I don't find that to be a disadvantage in practice. While CUDA supports a fairly useful subset of C++ (most notably, templates), I still find host-side metaprogramming to generate kernel code to be a much more useful approach in most cases. Of course your preferences may vary, but I haven't seen many experienced GPGPU people express dissatisfaction with this point.

False. The official wrappers support C++ from OpenCL 1.0 on. Maybe this isn't obvious because the C++ bindings were introduced later, but they're backwards compatible and you can set the target API level. (And of course you use 1.2 if you need to support lagging vendors such as NVIDIA)

I have no idea about the other languages but surely other bindings must exist?

No one is speaking of wrappers here, rather C++ kernels, which is what matters, a full C++ experience.

> I have no idea about the other languages but surely other bindings must exist?

Yeah, the usual poor man's solution of generating C code, thus introducing two compilation steps, without any debugger support.