I won't speak to the finishing touches that give an iPhone OS device that silky smooth organic feel. If other optimizations are taken care of, certain things should just be a matter of parameter tweaking. Some of which Nokia just hasn't done yet. But even though 3/5 less pixels can't be swept under the rug, as well as the responsiveness of a capacitive screen, I'll forget about some of the differences and try to stay on topic.

A month or so ago I was doing some graphic stuff in Python and I wanted to see how often certain events occur. I was moving gtk.Images inside gtk.EventBoxes around a gtk.Fixed container, and on average, with normal movement, X was signaling about 40 non-linear gtk.gdk.MOTION_NOTIFY events a second. For what I was doing it looked and worked great. But if it didn't, I had plenty of room for optimization. All I have to do is fool the human eye. If I were to turn off gtk.gdk.MOTION_NOTIFY events and run my own linear timer at anywhere from 25 - 30 fps, I could reduce processing by somewhere near 30%.

Presently, I'm creating multi-column GTK scrolling tree views with mildly complex text and image rendering in C. Again, stand alone it's looking good, but because of the flexibility and power of these data structures, it's easy to get yourself into a compute intensive situation quickly. Throw in the frequency of the signaling I mentioned above, and it should be obvious that some default behavior might not be optimized.

If you know the history of the Macintosh, then you know it's always been about the UI. The original rendering code was assembly language put into firmware! Quite the opposite of X. To this day, a normal application on a normal Mac can't display it's output to just any ol' frame buffer. But X has been client/server based from the beginning. That too was 1984, yet philosophically, they've been polar opposites.

I also program in the iPhone OS environment. And I can verify how some of the application launching and monitoring work. There's good stuff going on there that has yet to permeate mainstream GTK development; I can't yet say for Qt. For example, the iPhone OS will proactively send signals to applications, suggesting they free up memory caches. Maybe something multi-tasking handheld OS's might want to do. Remember, we've inherited a desktop platform, but there's no need to cut corners. With the combination of MeeGo and Qt, these types of issues should become much higher priorities. But at the same time, we can't trivialize that some of this stuff might go all the way down to the kernel scheduler.

Out of respect for the OP, and there being no need for redundancy, I won't mention the trade offs of using an iPhone OS device. But as far as I'm concerned, the future looks bright for a silky smooth organic Linux. And as much as a resistive screen will allow, that should include the n900.