In addition, when scrolling, iOS's main thread goes into a "tracking" mode where it filters out certain types of events that might result in redrawing or other performance degradations
He calls it tracking mode; the full name is a "run loop mode"—specifically, UIEventTrackingMode. When you're scrolling or zooming or transitioning a view, the main thread restricts which actions are performed: timers do not fire, sockets are disabled, and many other tweaks. This is why animations on iOS are so smooth (in my opinion).
I/O in the main thread and GC are also common culprits. StrictMode is helping with the first. The latter was improved in Android 2.3 with the concurrent garbage collector. There are still more improvements that can be had there, but like I said, HW acceleration is the biggest win. When apps start optimizing for HW acceleration, allocations will likely decrease (because the apps won't be re-drawing on every frame), and GC overhead will become even less of an issue.
As you say, I/O in the main thread and GC are central causes. Both are problems that Apple doesn't have, because of run loops and manual memory management respectively.
Also, the focus on multithreading the heck out of everything is not the way to go. There is real, substantial overhead to having multiple threads. Run loops are such a powerful tool precisely because they let you keep everything on the main thread (avoiding context switch overhead) while giving you an easy way to prioritize UI when needed (event tracking mode).
