Well, fast forward about two years, and that script is still sitting around on a forlorn webserver of mine. Somehow, I have no idea why, some random person ended up tweeting a link to it and it spread around a bit until the software vendor got wind of it. They ended up sending me a probably too-polite email asking if I could do something about it, and after a bit of back-and-forth I got instructions from them on how to enable more secure "long URLs" in the software (an option that I think was new since I made it, so I wonder if I may have actually inspired it...) and added those to the bottom of the page.
It's long gone now, and to be honest I can't remember which app was affected. Possibly tinygrab.
The point of this anecdote is that the problem is not at all new, and the problem of how to deal with it isn't new either. I suggested to the developer at the time that they should probably use long URLs by default, but it seems users just like those short URLs too much. Going to non-sequential assignment would have helped, but the space was still just too small.
Really, I think the fix is just communication. Microsoft's workflow used to be sensible in that OneDrive gave you a long URL and then you had to click another button to get a short one. That second click should come with a warning that there should be no sensitive information in the document, and it will potentially become public after shortening. Users will have to be trusted with the judgment, at least you've CYAd.