thanks for the nice comment.
I can't speak for the entire Microsoft on such a broad topic, but I can certainly give you my opinion.
1) the alleged complexity of WS-* is invisible to the vast majority of developers and architect, in the same way in which everybody happily ignores the backoff algorythm that TCP uses for resending packets or how HTTPS acquires certificates and secure the session.
Unless you're in the business of writing network stacks, you can ignore all WS-* details exactly like today you can ignore how COM+ manage to propagate a transaction.
2) WS-* covers an amazing amout of aspects. It is designed to be modular, so that you can consider only the set of specification spertaining the capabilities you are interested into. If somebody remembers Corba, I'm sure it would be enough to make a quick reality
check in this respect.
The things it tries to accomplish are advanced, so a certain level of sophistication is intrinsic in the problem. The WS-Security subfamily is a good example: it's not just a matter of throwing a bunch of XML elements from A to B, it's allowing different technologies
to interoperate in a uniform encapsulation (X509, Kerberos, SAML, u/pwd, they are all normated in the Security Token pattern), propagation and negotiation of keys, selective signatures/encryption, automatic negotiation of policies, secure session management...
those are COMPLEX things, nonetheless they are needed in various situations (especially inside the enterprise and in enterprise to enterprise interaction)! We are paying the price of the negotiation once, so that the industry can then use those capabilities
in interoperable fashion without going through that pain: but somebody has to pay that price at some point IF you want those advanced capabilities. That does not mean that WS-Security is a swiss knife: there are scenarios where it may be anti-economical to
make use of it, because you have simple needs/tactical constraints/strong hypothesis. Again, if a scenario you're considering does not need the capabilites supplied by WS-Security does not imply that WS-Security is too complex, nor that there are no scenarios
where WS-Security adds enormous value: it simply means that you don;t need WS-Security in that scenario. It's that simple
3) things like the Metasystem are enabled by the sheer existence of WS-* and consensus around it. Anything less generic and future-proof would not be able to provide the strategic solution we so desperately need in the identity space. And that's just one of
the most visible problems in today's computing scene, I believe it will prove the value of building over those standards and will accelerate similar solution on other spaces
4) about WS-Transfer, specifically. It may have the same expressive power of HTTP or occupy an equivalent ecological niche, and I don't want to validate or deny that statement, but that's not the point. The point is that it's a module of an ecosystem based
on more generic rules, and its value is in the composition. If I have all my phisical routers exposed as WS-Management compliant endpoints, I can use WS-Transfer on whatever transport for obtaining the fitness data I need. If my routers listen on a highly
optimized TCP channel, why would I want to dive out and wrap them with HTTP? Or why would I need to add adapters around, if another device offers the same WS-Management endpoint on a queue and I want to aggregate their results? The point here is again context.
Would I use WS-Trasfer for getting a list of products from Amazon and render them in a browser? Probably not, HTTP is already there for that. Would I use HTTP for probing my server farm and my network hardware, for aggregating a massive live data stream in
the console I use for managing my multitenant application (that maybe SUPPLIES the product list that one of the tenant will download on his browser)? Well, you can imagine my answer