You (and most other people) need to realize that there is a relatively small set of computations that can be accelerated by this kind of technology. Of course certain types of video, image, and sound processing will work, but your run-of-the-mill Mac app isn't going to be able to take advantage of GCD or OCL.
This is patently untrue. Many, many common operations could be easily multithreaded if the cost -- in terms of development technique and setup/teardown of new threads -- was not so prohibitive. That's the problem GCD aims to solve.
Consider a typical function that performs some sort of IO, do a set of 5 or more independent operations (such as applying filters or validation), and then record the result of those operations. Ordinarily, we perform these three stage in serial, and once performance becomes an issue, we go back and re-implement one of the stages (usually the IO) in such a way that it populates a synchronized "queue" of results, which can be handled by another worker thread. Rarely do developers go more than three threads deep, because it's difficult to think about three things happening in parallel. GCD purports to change that by allowing developers to state parallelizable blocks in a way that's just as natural as a for loop. Assuming you had enough CPUs, you could launch all 5 independent operations at the same time on separate threads, and coordinate the result when they all completed. Of course, if you only have one CPU -- what is this, Russia? -- the code executes same as it did before.
Another example is event multicasting (the issuance of requests to handle an event to more than one registered recipient). Typically, multicasting is also performed in serial. However, it's rare that multicast clients are dependent on each others' results, in part because the order of dispatch is often nondeterministic, but mostly because the whole idea of event multicasting is to give the illusion to the user that many things are happening at the same time. It's quite possible that, in a cast where clicking a button should result in several UI mutations (such as the button being greyed, the cursor changing state) as well as one or more independent background operations. No developer is going to manage a thread stack to perform such trivial operations, but every developer will need to write a block of code to manage them. If the act of turning this block over to GCD is as simple as writing the block a little differently, and brokering a call to GCD, the barrier to multithreading is eliminated.
What about logging? Every application logs something somewhere, and most of them do it in serial too. I recently wrote a log adapter using plain old non GCD threads and it boosted our apps performance by about 20%.
As for OCL -- I've read papers claiming benefit from using the GPU to handle such basic tasks as string operations and node traversals. Any task where the number of operations exceeds the size of the data they're operating on can be pushed onto the GPU for a performance bump.
Most of the time, multithreading and GPU computing are ignored in an application's development because developers make the same assumption you do, that the average operations isn't likely to benefit from them. This is done because performing this kind of optimization when it isn't needed is costly and error prone -- "Do not preoptimize" is the motto of any developer whose tasks are more complex than Hello World. The beauty of OCL and GCD is that they allow developers to make relatively minor changes to the way they write that vastly improve performance before even the first pass of optimization occurs.
