Here's what usually happened:
* Testing got slow. Rather than just running a bunch of tests with nose or pytest, you had to provision a number of services, sometimes on a VM or build slave.
* Testing got bad. Because services have enforced privacy, you can't test or mock their internal states, so you have a bunch of happy path functional tests but much less in the way of comprehensive unit and integration tests.
* Communication deteriorated. In a perverse corollary to Conway's law, our team struggled to maintain a system that didn't mirror its own structure.
* We spent a long time re-implementing basics (auth, JSON serialization, parallelization), and less time building product. This was always justified to the product owners as a necessary short-term sacrifice, but it ended up being a long-term sacrifice too.
* Security failed -- distributed systems are harder to secure than monolithic ones, and most of the small companies trying to execute SOA don't have a clue about application security. The fact that they don't have robust implementations of common components available to them (because auth is now handled as a service, for example) doesn't help.
* Performance degraded: HTTP, JSON and TCP are slow compared to passing around objects in memory and pushing to the stack. They always will be. Most people forget that the database is more than a dumb repository of tuples, and thus end up reinventing the relational algebra in JSON—only with horrendous performance.
* Reliability was hurt. The idea that you have multiple services that can each go down without affecting the whole system is an absolute pipe dream. If the database goes down you can't do anything. If the web server segfaults, no one can see your site. End of. And things are far more likely to fuck up when you try to build a distributed architecture. You probably don't have the time or money to implement the correct provisioning or monitoring either, so when stuff does break you're gonna have a really fun time discovering and debugging it.
These are just my experiences from being on teams of a few people. In larger organizations I'd postulate that SOA is the better approach. But please don't fall into the trap of buying SOA before you've reached a definite need for it.