I'm no expert, but hopefully by abstracting out different services from your core app and making them available through some connection protocol (Thrift, a message queue, http, whatever) you can more easily scale up and scale out systems that become hotspots, and consumers of that service will never be any the wiser, since they only interact with it through the published API.

Looking at it another way, when I talk to the GitHub API, I have no idea what sort of database I'm ultimately talking to. Their interface abstracts away all of that complexity. Each request they receive from me might be handled by a different machine for all I know. It makes no difference.

By itself SOA doesn't do anything but it does free you up to do other things that allow you to scale like read-write separation and event driven or fan-out caching. One of the most important thing SOA does is that it quickly stops you from doing dirty hacks that work right now but are killers for future work. It's encapsulation at the application level

Service orientation allows specialization of architectural components. If you want to build on scale, it is easier to replicate specialized components than a generalized one. It also benefits from better fault tolerance.

Additionally, services layer forms an interface between the client and service provider, which makes it easier to scale.