VC works great for source code because it's all line based with (either by convention or required by the grammar) one statement per line. Diffing is pretty trivial in these cases and meaningful.
Binary formats are a whole different ballgame. Even XML-based formats are problematic. My view is that XML documents require a VCS built specifically for diffing that kind of data as line based will run a lot of false positives with white-space.
As another commentor said: you can always get your stuff back with Dropbox. I'm not sure how much better you can do than this without actually changing the program that created the data.
There are .NET interop assemblies[1], for working with Office documents, and they require Office to be installed to work. Outside of that, you're stuck rolling your own Office-document-parser.
There is a built-in "track changes" mechanism, though I don't know if all Office types handle it. Word does, at least. Though that's pretty basic.
I'd like a local-conflict view, yes. They do actually exist on your machine (in a hidden folder inside your Dropbox folder), Dropbox downloads all conflicts all the time. I ran across this behavior when I caused a conflict in my work TrueCrypt file - pulling a gig took a while. But the web interface is almost entirely useless for comparing such a file, or any file metadata conflicts, because you need to open it to examine the contents.