SOAP is used in two basic ways, as a tool for doing RPC on remote systems, and as a messaging service.
When SOAP is used to perform RPC the parameters passed and the return values must be consistent with the SOAP data model (unless custom encodings are used, more on that later). This model is relatively simplistic, it contains a collection of atomic types, arrays, and structures. In the SOAP data model values must be associated with each instance of an atomic type, this includes members of an array or structure.
Given the type constraints and the embedded value requirements of the SOAP data model it is not practical to try to shoe-horn the OPeNDAP data model directly into a SOAP data model representation model.
In order pass our DAP objects via SOAP methods we have 2 choices: Extend the SOAP data model to cover our custom data types (so that our types can be used in an RPC request) or rely on SOAP messaging.
Custom data types require the use of custom serialization and de-serialization classes that must be integrated into the SOAP server (and client). These classes are tightly coupled to the particular implementation of the SOAP engine (such as Apache AXIS, GLUE, etc.)
Messaging allows us to pass W3C DOM trees back and forth between server and client. Each side can then act upon them as necessary (parse them into a Java/C++ class in memory, extract pertinent information directly from the DOM elements, what have you)
Using a SOAP messaging scheme will cut us off from the automatic WSDL generation tools that have been developed for the SOAP RPC model. However, this may not be such a large issue. Ultimately, having a custom data type in an RPC call only buys you the information (at the WSDL level) that this method requires (for example) a "DDS" or a "ConstraintExpression" but probably doesn't lead you to an implementation of such a beast.