The Android SDK is a bit too Java-ish for my liking. I mean, yeah, it is written in Java, sure, but some Java libraries/frameworks are able to live in Java and still feel light. While the Android SDK isn't EJB-bad, there is too much unneeded abstraction in most of the SDK, IMO, a feature which I tend to associate strongly with Java in general.

On the IDE issue... while Eclipse's 'quick fix', logcat plugin and powerful intellisense features are awesome, the horrible bloat cancels out all of the nice features. I'm frankly amazed how slow it can run on a new i5 system when everything else flies on it and I'm constantly annoyed by the sloppy way it is integrated with the Android SDK code generation system resulting in a situation where a build can randomly fail and then work if you hit rebuild without changing anything. I've basically given up on using Eclipse as the primary editor and now develop my Android apps in Sublime Text 2 and use an ant-based command-line build solution. I highly recommend ant (over Maven which he mentions in the article) simply because the Android SDK is already very ant friendly. Chances are good that building your project will Just Work in ant, especially if your dependent libraries are properly using the Android SDK and available via custom library sites through the Android SDK Manager. Sublime Text 2 has a good logcat plugin available via Package Control. The only time I fall back to Eclipse is when I have to do on-device debugging.

GUI Editor: I don't use the Android one, I write XML by hand. Yes, the Android GUI editor isn't that great (though much better than it was before). This is at least partially related to the non-pixel-perfect layout issue. Writing a GUI editor that allows for fully reactive UIs is a much more difficult problem than one where the elements remain fixed. Having said that, the Android GUI editor could be a lot better.

The duplication of XML files is another issue I agree with. I actually like declarative XML for UIs. If Android had a good property binding system and it was integrated with the layout XMLs, you'd be able to have single XML files that could powerfully lay themselves out properly for different orientations and resolutions without having half a dozen different XML layouts for the same view. This is an area where Android should crib from Adobe Flex (or WPF, but avoid all the special DependencyProperty bloat) rather than iOS.

StackOverflow: He's sadly right here with one exception. User "CommonsWare" is a great resource. A lot of the other people who answer Android questions are clueless and will just lead you down paths of stupidity. I highly recommend just downloading the Android AOSP source code and if you have a question read through the base classes. It would be nice if the framework classes were simple enough that you didn't have to do this, but to understand how tabbed page adapters (as one example) really work, you basically have to dig into the Android code because there is a lot (too much, IMO) of "magic" that happens under the covers in many cases and it isn't good "magic" because if you don't know about some of it, it will bite you in the ass.

Pixel-perfect UIs just aren't possible when you're developing reactive/liquid layout apps. This isn't a failing of Android, it is just the reality of developing for a platform without a small set of fixed resolutions. Tell your designer to suck it up because outside of iOS, reactive designs are the future.