I'd like to know too. There are a lot of people here rubbishing SOAP without explaining why. I've consumed, simultaneously with hundreds of other developers from disparate teams, 100s of SOAP services across a number of financial institutions and any issues I ran into had nothing to do with SOAP. Generating code with SvcUtil is great and does what it's supposed to - and nothing stops you from refining it or writing your own service clients.

I don't need to run service calls from the command line - I have version controlled integration tests that I right click on and select "run", as should every major consumer of serious services.

I don't believe SOAP web services are always the way to go (I've never used any in my personal projects, preferring my own web API and/or a service bus), but that doesn't mean it's not suitable for other problems.

What's often missing from these debates is defining what environment you're operating in (legacy and dependant systems/platforms/interfaces, network architecture, how much architectural control you have, user load, number of developers, number of teams, release cycles, politics [what was the last big budget item that was purchased to solve the current problem], timelines etc.). Once you start identifying the environment details, some of the simplistic unqualified suggestions people make in these debates seem naive and ridiculous.