DITA has been around awhile now, but is not universally used by technical documentation teams. However, it has become the most popular standard in structured formats for technical writing, overtaking the likes of Docbook. I suppose one of the main criteria for moving to DITA is translation management. DITA is a great cost-reducer for any company that must translate their documentation into multiple languages.
But, it’s not DITA itself that makes the content easier for translation management, but how much easier it is to have structured documentation (like DITA) managed in a CMS (Content Management System). It is the CMS that makes the translation management easier and more cost effective, but it relies on a structured framework of topics and reusable content to meet that aim.
A translation company will keep a translation memory (or bank) of all the words they have previously translated. Any word that is new is more expensive than a word that has already been translated.
Generic text cuts down on the translation cost because the translation memory can identify the words. Topics that are reused in multiple topics only have to be translated once.
DITA helps with the translation management by making topic reuse easier through the use of DITA maps (basically a Table of Contents for each document) where the same topic can be added to different DITA maps. Although what is generally not really documented anywhere I have seen (maybe it is taken for granted) is that to get to this step, you must have a very stable content management system in place. And generally, a CMS is the safest option.
A CMS can be viewed as an extra layer of structuring on top of the content structure.
To summarize, DITA (or any markup language/standard) structures your content at topic and TOC level to make it easier to reuse. And, a CMS structures your topics and maps/TOCs to make it easier to send for translation and also to store multiple map files and have one standard method for creating PDF/html etc. outputs.