SOAP is fragile, bloated and slow. It goes against what the very essence of a service should be, i.e. to expose functionality in as accessible and inter-operable way as possible.
The higher up the WS-* stack you go, the less supported it becomes - eventually only the Big Enterprise frameworks from MS and IBM support the complete WS-* stack.
WSDLs promote code-gen and as different SOAP frameworks have varying levels of WSDL support, you often end up with broken + ugly code-gen when trying to consume from different SOAP stacks. SOAP is also a brittle format where even a small namespace change can break the entire request, this makes versioning (a core part of evolving services) extremely difficult.
I generally prefer clean HTTP APIs with Cool URI's and JSON which is a much faster, smaller, more versionable and tolerant format that provides a better programmatic fit than SOAP/XML: http://www.infoq.com/presentations/Heretical-Open-Source
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.