It is not Mac v/s PC all over again because android can also be shipped without google. Windows cannot be shipped without Microsoft. It is also not mac v/s PC because a rival had a considerable share of revenue stream of android. (Much like if linux had a revenue portion of windows) And android's owner has different plans for earning money off of android. Mostly by search traffic and store sales and negligible for licensing.
You can talk about those differences, and of course it's not a 100% analogy, but I think his main point was about the market share and the ecosystem. If Android ends up with 3 billion users in 2015, and iOS only 1 billion, as predicted (also with the whole of Windows at 1.5 billion users, from 1.3 bn now), I expect most developers will be wanting to develop for Android first by then, and it should be their #1 source for income, too, simply through sheer numbers of users.
Having done corporate grade mobile work, there's no question of which platform is easier to develop for. On Android, not only do you have to simultaneously target in some cases four or five different API levels, you also have to hit several combinations of screen dimensions and resolutions. The documentation for Android is also lacking in comparison to the iOS docs. The android SDK, though comprehensive and generally very high quality, suffers from the same complexity problems arising from issues related to fragmentation.
Remember though, most of the developers who are doing work that actually matters on mobile aren't doing it because they want do, they're doing it because a corporate strategist thought it would be profitable use of their time.
I haven't found this to be the case at all. With the compat libs you can pretty easily target 2.3 and 4.x. And the dynamic layout issues are more than offset by the much greater flexibility of Android's layout managers.
An iOS app I'm working on right now has been a nightmare in comparison because we had to port our layouts to the i5 form factor but can't require iOS 6 just to get autologous. Apple really blew that transition.
Still: how many currently deployed devices running iOS are you going to be QAing that application on? Two, maybe Three? How many versions of iOS are you going to be seeing on those devices? One or two most likely, iPhone users tend to upgrade with their software with much more conformity and faster. Compare that to Androids upwards of fifteen (and growing) widespread devices, and a heinous amount of API levels in the wild. That's one of the more objective factors which make Android easier.
Also, you can say that the API level differences don't matter because they are hidden by compatibility libraries like The Support Package, but the truth is that those are just the newer APIs re-implemented against the old interfaces. You pay for that extra abstraction with wasted cycles and bloat, and it's an ugly solution. Even still, those libraries aren't perfect: there have been subtle bugs or incompatibilities introduced by their use which are notoriously hard to find. Finally, even if the newer APIs are present on the device, The Support Library will still be used (last I checked, though I think they are working on this).
Less objectively, it's a matter of preference. Some people just prefer objective C to a JVM compilable language.