The gist of the problem boiled down by Munn:
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.
Munn also broke it down in real world terms by providing the example that if you put your finger on the screen of an iPhone or iPad and move it around when it’s halfway through loading a complex web page like Facebook, all rendering stops instantaneously. The website will literally never load until your finger is removed, and this all boils down to the fact that the “UI thread is intercepting all events and rendering the UI at real-time priority.”
There are also some other reasons, like inoptimal hardware. The NVIDIA Tegra 2 CPUs ubiquitous to many Android 3.0 tablets and some phones suffered from low memory bandwidth and lacked NEON media instructions, both of which ultimately presented a bottleneck to the Android user interface and experience. However, Android 4.0 remedies this by having graphics hardware acceleration, although as long as graphics aren’t given top priority (a la real-time), platforms like iOS or Windows Phone 7 are always going to be more fluid.