Support for the Tcl client stubs is an interesting one in terms of persistence and dynamic loading of the stubs. And, there's the cost of generating the stubs and who'll do the work and how often (client or server.) Certainly, the code implementation for stub generation is nothing more than an excercise. In light of your level of interest and the benefits you point out, I'll give the issue greater attention.
For now, if you're interested in the soap-gateway package, I recommend using whatever techniques you now employ to generate your stubs. Most likely, I'll provide another parameter in the WSDL fetch that allows a developer to specify stub generation. I've done this for C++ in another project and I can certainly do it for this one as well. The first blast would target the OpenACS/ns_xml/tcl combo. Upon fetching the WSDL generated code, you'd park it somewhere in your OpenACS code base. I'll extend the SG's source library management pages to include stub management.
Out of curiosity, what flavor of complex types do you require? Basic arrays, structures, arbitrary ranges within multi-dimensional arrays....
Ah, and there's still the issue of attachments... what are your thoughts on the DIME spec?