This question is like asking why your application doesn't quote the description before returning it to TWiST, this is a programmer's decision when crossing the boundary of an application. TWiST takes the data you give it, assumes that you have given it the correct data, in the format you have chosen, and then handles it.
BTW, this issue provides a perfect example of why I setup TWiST as a 'configuration', not as an on/off switch for a proc like you get with .NET. This provides for maximum code reuse.
Imagine if you had to go back and define another internal API just to quote some output so TWiST could use it. The TWiST API <ws>proc is designed to allow you to call your internal API, do what you need to the normal inputs or outputs, and return the result in a format of your choice, completely independently of the exact internal API signature.
This idea should become very useful for procedures defined via ad_proc, where there are optional switches and the order of attributes isn't well defined. You can use <ws>proc to handle common defaults, and to prevent complete exposure of the internal API. For instance, you would not want to allow an application to choose the current user_id without validation. (OOB validation isn't handled by TWiST since it is OOB and application dependent.)
Also, you asked earlier if you could validate an output prior to sending. You do this inside of a <ws>proc.
There is no built in way to do this because the server should know that it is constructing a valid document. But it can be done inside the <ws>proc.
Once you have the data ready, feed the same thing you would return from <ws>proc (a list), to create a return message, then feed this reference to the validation routine. If you get an invalid result, you should return a server error (500).
Offline, you can do the same thing. Call your newly defined <ws>proc (in your new namespace) to get the return value list, create your XML message document, and then validate. This setup skips all the SOAP stuff, network interaction, etc. This is also a good place to do your unit tests.
If you have examples of what you are trying to do, it would benefit everyone if you would post the TWiST configuration, or parts of it. Real world examples are the best way to explain how things should work, and, as I said, they benefit everyone.