Short answers:
- it's very well possible to manage CDF-documents in a source control system, but you will loose some of the more attractive features of such systems.
- most probably any system will do equally well (or bad).
Some elaboration:
I don't know TFS, but all source control systems I know basically do work line oriented with plain text documents (which is a very common format for source code after all). It could well be that some source control tools can handle other formats, e.g. office documents, but that I don't know and I'd be very surprised if any could handle notebook files.
CDF documents basically are just notebook files with a signature, and notebook files are plain text, but unfortunately not line oriented but "cell oriented". That means that line breaks will be added and removed even when the content actually (or appearingly) has not changed. Notebooks also do contain formatting information which you might or might not want to be source controlled and they contain caching information which you probably never want to be source controlled.
AFAIK there is no source control system which is aware of CDF-documents (or notebooks), but I think almost all of them will handle them correctly as "binary files". That means they can identify whether files have changed or not but can't provide you with useful information about what has changed or do automated merges in a meaningful way. So many of those features that a source control system makes really useful will not work. So the answer is that yes, you can manage notebooks and CDF-documents in probably any source control system you like, but you will loose much of its power, and I think there is not much difference between them concerning the handling of those files.
There are some tools out there which will e.g. remove the caching information on checkin or remove the output cells of a notebook before checkin, which makes some sense for notebooks. But since the signature of a CDF document will become invalid with every change to the document, I don't think that is an option for CDF documents.
Another thing to have in mind is that the FrontEnd now handles package files reasonably well and there is also the Workbench, so interest in that direction has declined over the years, and most of those tools seem to be somewhat outdated.
Another tool which compensates for the fact the the source control systems can't handle notebook files is the notebook diff that newer versions of Mathematica (or the workbench?) do install under the hood and which pops up rather unexpectedly when using some version control systems and you try to compare two different versions of a notebook. I haven't investigated where that is stored and how you'd configure a source control system to use it if that isn't handled automatically, but you might want to get that working. That at least lets you compare notebook differences much more comfortable then any pure text utility. Another tool worth mentioning is the notebook diff tool in Workbench which lets you make a "diff" on the notebook expression of two notebooks and shows that in an extra view. But that view is rather something for a Mathematica programmer interested in the structure than for someone working on the layout of such a document.
One more thought: The best thing to do would actually be to generate those CDFs automatically, as WRI is suggesting e.g. in the CDF-Workshop (specifically here). You could then only put the generating code into source control and treat the generated CDF-documents as "generated content" like compiled binaries, which of course would not need to be stored within the version control system. But since that would probably be a huge change in how your users have to work, this might not be something you can inforce. Anyway I think it still should be in this answer in case someone is reading it who has the chance to make such a change...
Yes Mods, best to move to SO (replace tags to Sourecontrol,ALM, Math etc)
... @Ajasja You are right on target, but Git? - please elaborate and put your comment as an answer. The question is managing the cdf files in source control with MS Office ability and multi-users tracking. $\endgroup$