Username or EmailPassword
The fact that Android essentially had no legacy code base to try to move to a touch platform made it much easier. Microsoft was worried about keeping the PocketPC / CE apps going, RIM had their Blackberry users, and Nokia had their base. Adding fundamental touch support without screwing over existing apps where UI interactions were designed totally differently (interface elements too small to touch effectively) because of the working assumption of a keyboard, buttons or stylus - not as easy to respond to. Look at Microsoft's final answer: drop the old mobile OS entirely.
From Thom's original article: "In other words, unlike iOS, Android was built to be flexible, and run on many sorts of devices, with different screen sizes and form factors."
The fact that Apple optimized their specific UI for a more controlled set of sizes and touch input certainly doesn't mean the OS is somehow less flexible. If you mean the UIKit framework, sure, that assumes a touch interface - but the core of the OS has made it from NeXT workstations to current desktop machines, laptops, and phones and across quite a few CPU types to boot, and the lack of multitude of screen sizes had more to do with Apple not making 15 product variants because they didn't think it made sense.
Apple TV runs iOS. iOS handles non-touch input just fine.
iOS - UIKit specifically - doesn't have event processing at the SDK level for mouse or key events, which makes perfect sense since it's designed for a touch interface - mouse movement/clicking and key handling isn't the same as multi-touch.
I'd encourage you to take a look at how the iCade SDK has to work around the missing key events to get joystick and button events into games that support it. (Start with a hidden text field's delegate and go a bit downhill from there since that delegate doesn't know about 'key down' or 'key up' either...)
Again, that in no way makes iOS less flexible since it's a UIKit design question, and having mouse events - or in 99.9% of the time keyboard events - in UIKit would needlessly complicate event handling, but it's a stretch to claim it handles all kinds of input equally well.