I actually disagree with both views. I don't think making the GPU fully capable of running C++ is sufficient to solve the problem. I think this requires more than just memory unification and some instructions at the GPU level, I think it needs instruction level compatibility.
In my ideal future world a Computer has heterogeneous cores, that is some of them perform well on largely single threaded code, deal with branches well etc like todays modern CPUs and the other cores need to be used on mass with mostly calculations in order to function. Both support running of AMD64 instruction set and the operating system goes about allocating threads/tasks to the right core. The programmers role in all this is to hint about where a calculation would run best. Thus any program could start to utilise these additonal GPU cores even if technically it was never written to do so because the OS would assign activities to those cores when the high performance cores were utilised.
This matches closer to the way programs are written today and largely means that switching code from one core to the other is a matter of a bit of meta data for the thread and obviously setting up the multithreading to begin with. But having to write C++ in the middle of a python program for example so it can be passed to openCL and then run using C++ like data structures that is not the future and never well be. They will continue to see very slow adoption if they continue down this route, it will never become mainstream. Of all the solutions currently out there I have more hope for Intel's Phi to succeed than any of the others, although at the moment its just a computer on a board with a lot of cores rather than an actual core processor, but they are a lot closer to an ideal programming model.