For one, there is no SOAP or XSD. Chance of success just went up 10x because of that alone. Second, all the header cruft would not be in the XML document. Developers wouldn't be impaling themselves with generated code, schema problems, parser problems, etc.
Those headers would be *much* easier to parse (one would assume). Much less chance to cut ourselves on interop.
I would assume that some faction of REST/POX will eventually want to do something like this. In a previous post on HTTP, XML, REST, and $100, I mentioned event driven architecture (EDA). I don't see that happening without either this or the equivalent of what the WS-* world has (I saw on Tim Bray's blog EDA is being revisited in WS-* land). Including the headers in the XML document is what makes WS-* awful IMHO. With POX + HTTP Extensions (or something like it), the service developer would have the power of owning the XML contract outright (just has to be a well formed XML doc). You could add complexity as you went (via HTTP extensions), and the XML wouldn't change. Setting/Reading the headers could be set via configuration in relatively simple (compared to WS-*) frameworks. Seems like appropriate separation of concerns to me.
Obviously, web servers would have to evolve (plugins), but this path actually seems plausible - I just don't see WS-* resulting in a workable integration solution.
What's the catch?