Well I didn't really mean to suggest that it would be removed, mainly about what kind of performance hit I would take by using pthreads instead of Grand Central. In addition, how well will pthread programs and GC programs work together. Normally, the threading is handled by the scheduler in a straightforward model, but if the GC model modifies the scheduler model, I'm not really sure what the results will be.

You won't "take a hit", but you will "fail to utilize the hardware as efficiently as you could". Both GCD and OpenCL have their roots in open extensions to C. Both offer potentially significant performance gains for certain types of tasks. If enough developers find it advantageous to use either blocks or OpenCL, these technologies will likely show up on other platforms.

Regarding the scheduler, I'm not sure enough details are known outside of Apple at this point to know what the results would be on Snow Leopard. Your milage would obviously vary when porting to some other OS. It's easy to imagine that running a PThreads app might hog some cores, or be punished inappropriately by the scheduler. These things can happen when running more than one threaded app on a system today, without GCD. This behavior, even if not documented, should be relatively easy to explore with some simple demo apps, though, without porting your entire app.

And, uhm... you will need to refactor your application to take advantage of the new API. (Was that a trick question?) Apple's guidance indicates that you can make modest changes for big gains by focusing the refactoring effort on the parts of the app that do the most computationally. For some apps this can be a small amount of work for a large gain, particularly if you can take advantage of OpenCL as well as GCD.