That's a good and kind of provocative question ;-)
I have implemented many model-driven factories based on UML, and I never use sequence diagrams, for many reasons :
- they are difficult to apprehend by users (and this has a direct link to the main UML drawback : its complexitity)
- they could be used to generate some code BUT it would require that they are complete from an algorithmic point of view (which in turn requires high skilled and undaunted UML users, a huge amount of modeling time for only small parts of the software). When modeling even a simple for-loop is a kind of challenge, I seriously doubt that sequence diagrams could be processed for something useful...
- UML users are usually not developers. And sequence diagrams usually implement decisions that should be taken by developers.
To my mind, sequence diagrams can eventually be useful for (generated) documentation purpose, as they can explicit behavioral and process related aspects of the software.
NB: I only use UML as a vehicle for DSLs (implemented with uml profiles and specific ui tooling). And furthermore, my DSLs are designed to express only architectural concepts. I usually let developers complement the generated code with business behaviour and algorithmy, as I consider it is the most efficient way to express it. Model-level team members can define requirements in models, and/or participate to define tests and relevant test data to help developers implementing the logic.
If speaking representation of reality and efficiency, DSLs are definitely better !
But it requires an investment in the model-driven specific tooling that should be balanced with the expected benefits. In many circumstances, that can be a very good investment actually, since it has many advantages among traditional MDA/GPL approaches (model is simple and sustainable, generators are simpler, and you can capitalize on three diferent layers : functional (the models), architectural (your dsl metamodel), and technical (mapping decisions capitalized in code generators)).