(Further reading: http://developer.android.com/reference/android/view/View.htm... )
Edit: Also, I missed where she said that in her post: "Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default".
Unfortunately only the the Samsung Galaxy Nexus has Android 4 and I'm not sure there's anything other than a few tablets that have Android 3?
Google suggests toggling between LAYER_TYPE_NONE & LAYER_TYPE_HARDWARE pre/post animations. This need to actively manage view cache behaviour probably leads to developers being unaware of what to do.
LAYER_TYPE_HARDWARE enables smooth hardware-backed scrolling but glitches badly when the soft keyboard is visible (no resizing/panning of the webview, multiple seconds of delay between key type and text updates inside textfield forms).
LAYER_TYPE_NONE makes scrolling in the webview unbearably stuttering, but at least the soft keyboard becomes responsive, the webview pans correctly to show the field in which you're inputting text, and the key types are instant.
On top of that, there is the problem that you don't have access to keyboard show/dismiss events, so you have to inject javascript code to catch those in every page you plan your webview to display. This is at least the case on the Motorola Xoom and the Acer Iconia tablets running the latest versions of honeycomb.
The reason iOS is so silky smooth is because each view in UIKit is backed by a CoreAnimation layer which will be a pixel buffer in hardware. This means that if you move a UIView in iOS, no new rendering needs to be done of stuff that was "uncovered" by moving the view since each UIView has the full contents of its view stored in its CALayer. All that needs to happen is all of the layers are composited in their new positions which hardware will blazingly fast. However, as I understand it in Android, each Window (containing multiple Views) is one pixel buffer in hardware. Each view then draws in to that. This means that if you move a View in android, another view will be "uncovered" and since that area of the screen isn't stored somewhere, it has to go down the view tree rendering the now uncovered area of the screen. Even if that rendering is hardware accelerated, it's still going to be muuuuuch more work that just recompositing all the layers on the screen as in iOS, I mean imagine if there's text uncovered there? That's not going to be quick.
Now, there are downsides to iOS's approach - it uses a bunch more memory. But the upsides are basically what makes iOS good - all those silky animations. Android's just getting to a similar level of smoothness, but mostly only through better hardware.
(Caveat: How android works may have changed since I last looked, but that just makes the mystery of lack of smoothness even more interesting ;-) )