There is of course no free lunch. DITA's interchange features do have a cost, namely the imposition of some general constraints and rules that are necessary to ensure the system works.
In particular, a given DITA element must be at least as constrained as its immediate base type. This means, for example, that if the base type requires an "A" element followed by a "B" element then any specialization of the base type must provide "A" or a specialization of "A" and must require it to be followed by "B" or a specialization of B.
For example, because the content model for <topic> requires <title>, all specialized topic types must also require <title> or a specialization of <title> and must require the title element to be the first child of the topic element.
This means that markup designers do not have completely free reign to structure new markup designs however they might want to. It also means that it will not always be possible to make an existing non-DITA vocabulary into a DITA vocabulary simply by adding the appropriate @class attributes, because the existing vocabulary may not align structurally with the appropriate base DITA type.
For example, the general DocBook model for titled divisions does not include an element type that corresponds to the DITA <body> element, which DITA requires be used to hold the direct content of topics. Thus DocBook divisions are not structurally compatible with DITA topics.
The "at least as constrained" requirement also means that elements designed to be the basis for further specialization need to allow appropriate options in their own content models so that they don't prevent reasonable specialized designs. This is why the content models for most of the topic elements are so loose: they have to allow a wide range of possible specializations. It is important to remember that the base standard types were not intended to be directly used for authoring. They were intended to be specialized or constrained as appropriate for specific authoring use cases.
For example, while <body> within <topic> allows an unconstrained mix of block elements and <section> elements, <conbody> within <concept> only allows block elements before any <section> elements. But another specialization of <topic> might need to continue to allow a mix of block elements and <section> elements, so the constraint in <conbody> would be inappropriate in <body> because it would prevent other legitimate ways of organizing topic content in other specializations.
It's also important to remember that DITA, while developed originally for technical documentation, is not specific to technical documentation and therefore should not reflect markup design decisions that reflect editorial practice specific to technical documentation. DITA is a completely general XML application framework and must therefore accommodate all legitimate requirements within the general constraints of enabling interchange and interoperation.
To experienced XML practitioners the "at least as constrained" requirement may seem like a particularly onerous, or at least annoying, constraint, and it can be frustrating to realize that the way you would have designed a particular bit of markup in the past simply cannot work in a DITA context. It means that you cannot always create a blindly-literal mapping from legacy non-XML structures into DITA structures but will have to work out some amount of structural reordering and a bit of retraining of the people transitioning from the old system to the new. It means you will have to learn the basic DITA structural patterns in order to know how to translate specific requirements into conforming DITA markup designs.
But the important question is not about cost but about value.
The value of DITA is that it dramatically lowers the overall cost of system implementation, use, and maintenance while increasing the inherent value of content by enabling blind interchange over the broadest possible scope. This lower overall cost far outweighs the direct cost of specialization, while the increase in value of DITA-based content increases the value of the overall system. Even if a DITA-based implementation were no less expensive to initially implement than the equivalent non-DITA-based system, it would still have greater value because the content would have greater value and the ongoing cost of ownership of the DITA system will be lower. In fact, even if initial DITA implementation were more expensive than non-DITA options the added long-term value would still justify the DITA-based solution. But DITA-based systems are demonstrably less expensive to acquire and implement than any possible non-DITA solution that satisfies the same set of requirements.
That is, by accepting a few constraints on your freedom to define arbitrary markup structures and by taking the effort to learn the basics of DITA, you gain huge leverage that enables implementing very sophisticated XML systems with a minimum cost of both startup and ownership compared to any other way you could satisfy the same requirements using a non-DITA solution.
Part of the point of these tutorials, and of DITA for Practitioners in general, is to make the necessary knowledge available so that the cost of learning what you need to learn is lowered as well.
So while there is a cost to the specialization feature in terms of design constraints and increased complexity for general-purpose, specialization-aware processors and some learning of new technical details and concepts for practitioners, the value returned making the investment of those costs is remarkable indeed. And the value will continue to increase as network effects serve to make more and more DITA-aware knowledge and processing available, which means it's available to all. That suggests that an investment in DITA-based systems is the safest XML system investment you can make today.
As a practitioner myself I would refuse to do a from-scratch XML implementation that was not DITA-based for the simple reason that it would be a disservice to the client to do anything else, because anything else would be more expensive, both in the short term and the long term, than a DITA-based solution. The only non-DITA-based systems I work on any more are legacy systems that, for business reasons, cannot be (immediately) replaced with DITA-based equivalents. And it is painful for me to do so, because everything that DITA makes easy is hard in these systems.
DITA is a compelling technology not because it does cool stuff (although it does) but because through the specialization feature it dramatically lowers the initial and recurring costs of doing anything with XML for documents intended primarily for human consumption. Thus, even XML applications with the most basic requirements will benefit from a DITA-based solution simply because it will be cheaper, probably much cheaper, than any other XML-based alternative. And when you realize that you actually do need some of the really cool stuff DITA does, it's there waiting for you.