I disagree with you on points #1 and #2. A lot of very important web apps are very insecure if crypto-strong nonce URLs aren't good enough. Clearly relying on URLs is suboptimal, but it's a long way down from "suboptimal" to "vulnerable".
Sure, crypto-strong nonce URLs are better than unobfuscated URLs, but that's just one protection.
For example, let's say that Google accidentally leaks a directory listing of all files on a particular google docs server (or let's say an access log, to be even more realistic). If Google had properly authenticated access to these images, then the leaked access log would be worthless and unexploitable. However, without authenticating these requests, Google has suddenly caused a mass security breach, as hundreds of people rush to wget all the URLs before the images are taken down.
If Google is seriously expecting people to use their product as a replacement for a business intranet, then they need to take seriously all concerns.
But the insecurity of desktop document suites doesn't give Google a free pass on having lax security standards.
Of course, this is my evaluation. You and your organization are welcome to use Google Docs if you are comfortable with their security practices.
Also the fact that the image is permanently retained after the document is deleted is completely unacceptable. It's obvious that they are trying to save money on bandwidth and CPU here, but it's not an acceptable place to cut corners.
As for #3, I think that it's pretty easy to guess what this vulnerability is. It's probably the following: When you get an invite to view a shared document, either 1) Accepting the invitation after the document has changed and permission redacted still gives you permission to see it 2) After your permission is revoked, you can use that URL to regain permission to the document.