I agree that some of the WS-* extensions are extremely useful, but only if you actually need the functionality/complexity.
The services I write are consumed by developers at educational institutions around the world, many using nothing more than a quick-and-dirty PHP script. They appreciate the simplicity and ease of use - our read-only resources can be explored directly inside a web browser, and I point folks to the RestTest Firefox plugin if they need to experiment with our writable services.
However, I would hardly define our web services as simple... We've just done a lot of design work to make them appear simple. Through careful definition of resources, well thought out URL schemes that are human readable/constructible, and liberal use of XLink to point out related resources, we've avoided much of need for the complexity of the WS-* world.
With regard to WS-Security and WS-Trust - I've read and appreciated their specs before. Both appear well intentioned and well designed. However, the rest of the WS-* stack is so distasteful that it taints the gems that can be found. I'd rather take the concepts behind the specs, and implement the minimal subset my application needs. For example, see Amazon's REST authentication mechanism - simple yet effective.
As for WS-* interop, the base specifications are so complex that a complete web service toolkit is required to even contemplate interoperability. Even worse are the slight incompatibilities between major vendors - Microsoft's generated WSDLs for .NET services don't always map well to IBM's stack, for example (at least as of 2005).
I may have worded my initial post too strongly. Here's when I would consider WS-*
- Internal web services consumed by other resources at a single organization
- Homogeneous development platform across servers and clients, or enough time to work around minor interop issues
- A demonstrated need for more than a few WS-* extensions
