http://developer.apple.com/library/ios/#releasenotes/General... (referenced from the article) states

"WebKit on iOS now supports the requestAnimationFrame and cancelAnimationFrame methods in JavaScript, as described here: http://www.w3.org/TR/animation-timing/*

That link in turns states:

"script-based animations are most often performed by scheduling a callback using setTimeout or setInterval and making changes to the DOM to effect the animation in that callback.

A disadvantage of this approach is that the author of the animation script has no idea what the ideal frequency for updating their animation is. Instead, the easiest way forward for the author is to simply call setTimeout with a very small value, which in practice will be clamped to some minimum time like 10ms anyway. It likely won’t be the case that 100 updates per second are required for the animation, especially if the page is in a background tab or the browser window is minimized."*

So, it looks like setTimeOut is discouraged in favour of this (draft) standard. Given that, I would understand that Apple would optimize setTimeOut for minimal power use, rather than maximum update frequency (not that I have the faintest idea about how one should go about that)

Also: have you tried your claim about Chrome's performance in a similar amount of memory as what iOS has to deal with?

What's a better one, and how is it better? Mobile Safari's pretty widely acknowledged to implement a much better HTML5 experience, for example, and clearly it can be made to make good use of hardware acceleration for modern non-document-ish uses of CSS.

I think it's because Safari likes to cache the page as an image and avoid re-rendering it where possible. This is an assumption of mine, but I suspect it is the reason why position: fixed used to be broken on Mobile Safari.