SOA helps development and operations get aligned.
I've talked about how SOA can help achieve business/IT alignment. In fact, that's one of SOA's major selling points, that SOA can be applied to both the business and the IT department, making both composed of reusable services so that the IT systems look like the business.
One of my colleagues, Jorge Diaz, mentions this advantage as well: SOA helps align the development team with the operations team. In many companies, these teams don't work together well, with unfortunate consequences. The developers produce apps that require runtimes that operations doesn't support, or want to, or know how to. Operations deploys and runs apps differently than what development had in mind, such that they don't really run the way they ought to. The two groups don't coordinate to make sure that the running apps have the great quality of service (aka -ility) advantages like scalability, reliability, etc. The apps aren't written such that they can be managed and monitored effectively. These two groups need to work together, but often they do not.
SOA can help being development and operations together. SOA usually requires a runtime infrastructure; agreeing on what that infrastructure is goes a long way. Development creates apps to be deployed in that infrastructure; operations learns how to manage apps in that infrastructure. Development creates apps which not only have the desired functionality, but can be more easily and reliably tested, deployed, configured, monitored, managed, and diagnosed, which can make operation's job a lot easier and therefore more effective.
I think this development/operations alignment isn't as big a deal for those of us who come from a Java EE background. Java (esp. EE) provides a well-defined runtime and clear seperation between development and deployment into the runtime (mainly the EAR file with JNDI references to resources). SOA brings this seperation and alignment to a broader platform.