Is anyone surprised this happened? It doesn't actually raise any questions about the reliability. Those answers were known when it was built. The first rule of network programming: the network is unreliable. The real question is: why do we keep playing along, blissfully ignoring that?
For day-to-day work, the redundancy & reliability of something Google Docs is much greater than a client computer. RAID is expensive. Backplanes fail. Laptops fall. But now instead of waiting 2-4 hours for a reimage & file transfer, I can take a base image, go to docs.google.com, and be up and running in the time it takes to walk a laptop to my office. Or, if more pressing: in the time it takes to log in at my coworker's machine.
So I'm curious: what's with the pseudo-FUD?
Of google docs, yes. Of always having a network connection to docs, no. Maybe its just the environments I've been in, but at every client, employer, or place I've visited, my devices were more reliable than the network connection. Hell, last year the level 3 uplink for most of my state was out for a day.
In both cases you need a working computer to edit a file, but only one of them also requires a network connection. The only advantages you have are that software deploys faster because you're using a 21-centurly terminal emulator and the file under work is stored on the network.
Just because we as developers haven't put the solutions to quick and easy deployment of software packages and file redundancy into the hands of users doesn't make the cloud a panacea. We have these tools for us already. If my desktop fails, my latest-version files were on its hard drive, the network drive and usb flash drive, all synced after every save. I can grab a laptop or my co-workers machine and in the time it takes me to plug in a flash drive or just hit up a lan repository I'll have the files as they were at time of failure. If the other computer doesn't have the software, if I could hit up google docs on the other machine, I can easily smack 1 command into the terminal and in 30 seconds be ready to roll (and that server could be local, too, not relying on internet uplink). I'm not against relying on the network at all, but doing so in a manner that doesn't demand an always-on connection to get work done.
A solution that relies on the availability of network OR local machine and can gracefully handle the fault of one or the other is orders of magnitude more reliable than a solution that relies on BOTH network and local machine.
Also, let's not forget that for most people, minor downtime is a nuisance, not a real problem. It's annoying when I can't reach a web service I rely on, but it rarely if ever costs me money. With businesses, this can be a different proposition, but even then the savings from going "to the cloud" may more than offset any downtime costs.