Well done post, and definitely some interesting data to look at here.
The one point where I think you may have undersold Google is the interoperability of their Music service. They sell their music without DRM (similar to Apple) so it can be played anywhere. Also similar to Apple they have a player built in HTML5 so it can be accessed on most devices without even needing to download the song and play with a native player. This should be reflected and I believe should swing the interoperability category heavily in Google's favor since books and music are both accessible everywhere.
I think he may be a bit more alarmist than I can agree with but I will definitely attest to the fact that Apple is having some serious UX growing pains as they try to accomodate the largest and most international user base they have had to date.
Possibly the best one-liner comes from one of the comments: "I have been developing my own theory that Apple products are the technological equivalent to junk food, psychologically fattening an already physically obese populace. Like the Sun newspaper their products are encouraging us to be lazy and dumb down our intellectual capacities."
Synergy is good...if you can get it to reliably work with your setup.
I came across this keyboard/mouse sharing software the other day and have yet to try it out but it looks much more promising than synergy and claims there is zero configuration. (works on windows and mac)
I am an avid RIL user and have the apps on all of my various mobile devices. With the launch/rebranding of pocket though I am most surprised by the layout of the site when logged in. It looks visually like a tablet app, but I couldn't see myself ever using this on a mobile device because the apps are so good and actually save all your articles for offline reading. Designing a site to look this much like a mobile app on a desktop takes a lot of effort, and IMHO feels a bit clunky when using a full mouse & keyboard.
From a usability standpoint I would have expected the redesigned logged-in site to be primarily designed for desktop reading (e.g. smaller buttons, less chrome), and perhaps use responsive design to accomodate more mobile-friendly layouts when using other devices.
Overall I like the rebranding, new aesthetic and am excited to explore the new android app.
Most importantly though I'm SO happy my credentials/history just worked on the new site.
I use this service all the time since I found out about it last year (on HN) because it gives me more information than I will ever need and still makes it easy to consume. The most unique aspect of this implementation is the historical data they provide to give you an idea of weather even when there is no forecast. This is unbelievably valuable when planning a trip to a new region of the world and I routinely use it to plot my locations and timing accordingly.
The only real problem I have with this site is the heavy dependence on flash, and a few clunky UI controls when interacting with the graph over a long period of time.
As a web developer I have typically argued in favor of write once, execute everywhere robust web apps being the future of mobile interaction. Having built websites and apps designed to work well on mobile however, this typically leads to a stream of constant headaches trying to accommodate for the myriad of different mobile browsers and features each support/allow.
Similar to the way that different desktop browsers each roll out new feature support, and often times support features in completely different ways (CSS transparencies/gradients anyone?) mobile browsers have even slower and more varied support for features and interaction control. This problem with desktop browsers has kept most web developers and firms I work with from integrating the latest and greatest HTML5/CSS3 features in all their sites, because there is a huge handicap in trying to optimize for so many different platforms as each evolves on its own timeline.
Even though writing the same app to work well in both iOS and Android is a HUGE undertaking, the advantage is you are only writing your application to meet two different sets of API specifications. Even better yet since mobile devs are typically either iOS OR Android experts you can potentially have two different teams of devs working on the platform they know best instead of having one html team constantly striving to make your application work well (or at all) in a dozen different commonly used mobile web browsers.
I applaud Facebook for their efforts to build out a really great looking mobile web app that does look an awful like their mobile apps, but has anyone watched someone who doesn't know (or care) about the difference between a native app and mobile web app use it? I got a fairly tech-savvy family member a kindle fire recently and it comes pre-installed with a shortcut to the Facebook mobile web app because the native app is not available in the amazon marketplace. Watching over their shoulder I was amazed to see how frustrating the experience was for them when the querystring gets corrupted at certain points and all they are left with is a PHP whitescreen of death. No loading symbol, no ability to get out of the corrupted state the browser got itself into, and generally the user was left with no idea why this wasn't working as nicely as their Facebook app on iOS/Android that looks exactly the same.
At the end of the day I now lean more toward the side of mobile apps continuing to be more efficient and effective for apps that require lots of interaction with the user even if you could technically implement all those interactions in a browser. The relative simplicity of only having to code for two platforms instead of 12, and simultaneously providing your users with a more responsive experience is definitely worth it.
The one point where I think you may have undersold Google is the interoperability of their Music service. They sell their music without DRM (similar to Apple) so it can be played anywhere. Also similar to Apple they have a player built in HTML5 so it can be accessed on most devices without even needing to download the song and play with a native player. This should be reflected and I believe should swing the interoperability category heavily in Google's favor since books and music are both accessible everywhere.