If animating in javascript, every frame requires a new javascript turn, and every frame requires crossing the js/native bridge. Theoretically it should be faster to cross the bridge only once, which is possible when using translate because both x and y can be set in one crossing of the bridge, wheras setting top and then setting left requires crossing the bridge twice. However the cost of setting up and tearing down the turns required to do the animation in js would dwarf any tiny advantage gained by only crossing the bridge once instead of twice.
However if you instead simply use a transform with a duration and set the x and y to the final value instead of manually setting all the intermediate values, it's obvious why things should be much faster: there are no longer any js turns required to carry out the entire animation other than the first one where you set it up, and there's no bridge crossing required except for the first one, either.
Did I miss something here? Why would the author think that setting transform in a loop would be faster than setting top/left in a loop? They are basically equivalent. CSS animations with a duration are vastly different, however.
Besides, is it really obvious that top/left would be faster (in a non-transition case)? It requires an additional layout phase compared to transforms:translate().
On the common sense of transitions being faster, it is true that there will be overhead in running JavaScript code. But at the same time, 1/60th of a second is a very long time for a computer and (for me) the overhead of crossing the bridge and running a minimal amount of JavaScript was an unknown.
Being from the "show me state" I like to measure before doing any performance optimization work or making general claims.
Also, I think you may be surprised how much overhead crossing the bridge from js to native incurs. It's pretty negligible in most cases, but for things like animation it can be a killer.