I agree. These efforts are more akin to "XML-marketing Optimized Packaging". There were several attempts since the early days of XML to provide a marshalling mechanism for XML. They always fail when people realize that serialization / deserialization is expensive - often more expensive then the bandwidth gains that [theoretically] can be made by marshalling the XML.
I worked on an application once where we were dealing with large Java Objects being Serialized across different speed networks. We had to compress the messages because we had some users on very slow connections.
What I noticed, though, was that compressing the data actually slowed down the application on fast networks because the time cost of compression and decompression was greated than that of the data transfer.
Not completely analogous to XML but I have to agree that reducing the message size isn't necessarily going to solve the problem.
I think a lot of people think XML and SOAP are slow because they have worked with tools that have buggy or inefficient implementations. I know that Axis used to or still has a prolem deserializing messages that causes it o be extraordinarily slow. Something like 20 seconds to deserialize a one MB message.