Thoughts from one of my last projects. It is difficult to create a well-isolated component that uses a WCF client under the covers. WCF reads end-point configuration settings from the app.config, and there is only one app.config per application. This creates a classic “leaking abstraction” problem. I can’t just use the component by doing new MyComponent(), I also need to worry about some scary XML mambo-jumbo in the config file. And if I don’t get it right, the component may fail in mysterious ways.
WCF configuration settings are complex, verbose, and sometimes outright frightening. If my component goes to http://www.mysite.com/ for services, the only thing that might be of interest for external users is the URL itself. But WCF configuration contains much more than that: endpoint names, buffer sizes, protocol options, et cetera, et cetera. This makes it difficult to reuse WCF clients, and drastically increase the number of things that may go wrong. This is especially bad for CAB-like applications, when the list of the components to use is dynamic, and thus pre-baking everything into the central app.config is simply impossible. It would be nice if WCF had some kind of alternative config reader or something. Or maybe it does, but we don’t know about it.

Technically, WCF does not require config – everything can be initialized by hand, but this is not how things are created when you do “Add web reference”. Requiring component authors to program client access by hand is mean and impractical. They have enough headaches like it is, and won’t appreciate additional trouble.