When using CCEaseIn, one would expect the action, eg. movement, to start at 0 speed and accelerate from that. If the rate is 2, one would expect it to go at a speed factor of 2 by the end of the action (because the gradient of t^2 is 2 at t=1.) And that's exactly how it works.
One would expect CCEaseOut to be the exact opposite of that. In other words, one would expect (if rate is 2) it to start with a speed factor of 2 and decelerate until the speed factor is 0 at the end of the action.
But that's not what CCEaseOut does. Instead, it does this: "[inner update: powf(t,1/rate)];"
In other words, it's calculating the square root of t. This means that the speed factor is "infinite" at the beginning and 1/2 at the end (rather than zero.) This is not what one would expect, nor is it what it should do. Moreover, even the curve at http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:actions_ease has the form that one would expect rather than what CCEaseOut actually does.
Incidentally, CCEaseInOut does the "Out" half correctly, and unlike CCEaseOut does.
I would consider this an outright bug, and an annoying one at that. For example if you would want to simulate eg. a parabolic trajectory by using two CCMoves, the first one using CCEaseOut and the second one using CCEaseIn, it won't work properly because CCEaseOut is doing the wrong thing.
What it should be doing instead is "[_inner update: 1.0f - powf(1-t, _rate)];"