Like so many other "silver bullets", you have to look at SOA as a tool set and take what you actually need from it.
First, let me extol the advantages of the abstraction provided by web services in general (forgetting about BPEL and all that pie-in-the-sky stuff):
It forces you into loose coupling. You cannot reach into the internals of a web service whenever you feel lazy. It's just not an option. As a result, the API of each service grows out to be very extensive and robust in order to serve everybody's needs.
It lets you make any API public, whenever you want. This is a big deal in corporate because you will eventually need your system to interact with other systems. In many ways, system integration work has become a genuinely mundane experience for me because chances are, whatever we need, there's already a web service for it.
You can layer in certain horizontal features without ever having to change the API. It's basically Aspect-Oriented Programming at the architectural level; cross-cutting concerns such as logging and security and message queuing are literally just a configuration change away.
It massively simplifies deployment of smart-client applications (not so much for web apps). Yeah, it's sometimes a chore to have to go through the rigmarole of redeploying services and updating proxies and all that during the development phase, but that's made up for in triplicate by the number of times I've been able to fix some minor bug in a production system or implement some change to business logic at the service layer, and only have to worry about one deployment, as opposed to 100. Any middleware can do this; SOAP just happens to be the easiest to work with today.
These are real, practical benefits that I've actually experienced, and continue to experience on a regular basis. I won't deny that it's more work up-front to build and maintain web service APIs, but in the long run, it really does pay for itself if you follow proper practices (chunky messages, standards-based policies, etc.)
Now that, in and of itself, is not an endorsement of SOA. Web services are just one tiny piece of SOA, and at times the SOA train really does seem to go off the rails. But there's good and bad. Some choice elements that come to mind:
Service Discovery: Semi-useful, if you can get it up to the point where you're able to centrally manage the policies. Otherwise it's really incredibly tedious to have to remember or look up all the configuration and policy elements you need whenever you need to interface a new service or application to the existing ones.
Service Broker: Awful, at least in my experience. A broker is a highly effective way to introduce a new single point of failure and extend latencies by several orders of magnitude. I don't bother with these, or with any of the concepts that naturally follow (mainly orchestrations), unless I'm working with legacy systems that cannot be made to support...
Service Bus: Very useful specifically for publish/subscribe scenarios. This is the key to boosting (a) performance and (b) "intelligence" in an architecture. (a) because you can do batching, rate limiting, and denormalization to your heart's content, and (b) because the alternative is an inscrutable array of batch processes, ETLs, custom-coded scheduled tasks and other things that will make you go completely insane once you find yourself having to deal with 50 of them running across 10 different machines. ESB pub/sub is the non-crappy version of brokered messaging.
BPEL: Is one of those things that sounds really cool in theory, but when you put it into practice, it becomes like trying to drill a hole with a stick of dynamite. Or open a door with a stick of dynamite. Or grate cheese with a stick of... you get the idea. You get this extremely powerful tool that can ostensibly do just about anything, but in practice doesn't actually do any of those things very well, unless the thing you're trying to is blow stuff up, in which case it's an excellent tool for the job.
Now I've got nothing against REST either, but I think it'll be a while before we seriously start to see it being used in the enterprise world. First of all, there's just too much momentum built up around SOAP, and second, REST doesn't have well-established standards around transactions, metadata, security, etc. That's all totally fine and even a good thing when all you're doing is exposing an API to the public, but not so good when you're trying to integrate distributed systems into a larger architecture.
Finally, I say all this with the caveat that the cost/benefit ratio depends on the size of the project and the size of the overall architecture. If your company just started up 2 months ago and just needs a web 2.0 storefront then you are wasting huge amounts of time doing anything that I've mentioned. Just hurry up and get it done. But if you're in a business with hundreds or thousands of employees, multiple offices, a dozen departments, a financial system, a work order system, a CRM, sales force automation, inventory, intranet, customer self-service site and blah blah blah, then "do the simplest thing that could possibly work" ceases to be an intelligent mantra and you need to start thinking bigger.
And while you don't have to call it an "SOA", the ideas and patterns and technologies enshrined by that model are essentially the de facto standard for enterprise development. If you like to swim against the current, make sure you bring a life jacket.
