Here at the Applied XML Developers Conference in the center of the unknown world, Stevenson, WA, there is definitely a well-represented camp that believes that SOAP envelopes are not particularly worth while and we should just use SSL for security.
What you lose when you go to a non-message based approach is what you really end up gaining from having messages. Take the following scenario:
Suppose I know I'm creating a bunch of SOAP messages and I decide I want to get them all to some endpoint. So I check the local classified ads for someone who will deliver these messages for me. I find the following entries:
So you see these three options for having your messages delivered and you say, AHAH! There is an obvious choice here. That's right, the third one - Evil Eddie.
Why would we go with Evil Eddie? Because message-level security allows us to hand our messages to anyone. They won't be able to decrypt encrypted data, they won't be able to modify signed data, they can't do anything to that message that cannot be detected. What if Eddie starts modifying my messages? We will be able to detect that because the signatures will be invalid and we will throw those messages away. But what if I need those message? That is why we throw in WS-ReliableMessaging so that we will retry sending any messages that were not received as valid messages. We have paid nothing and Evil Eddie has done the job for us.
And it doesn't have to be Evil Eddie. Thinking in a message-oriented world means you can do a number of things. You can throw the message on a floppy and hand it to the person. You can send it in email. You can throw it in a database. You can post it to an FTP server. You can send it in an instant message. And it doesn't matter. You can deal with the message any way you want.
And as Becky mentions, this approach can avoid any sort of processing bottleneck, which among other things, mitigates denial of service attacks since you can queue up messages and process them as we get the cycles.