I think two examples from the real world can make you understand a little better why this is relevant. Alias, to tell the truth, when I read your question I became interested and went to search and saw that I have been working with this for some time and did not even realize it. Since I've never really heard of SOA I've written this answer more to try to help with some of the things I've noticed in my work and what I think are related. I ask those who really know the subject to correct me if I say anything stupid there. Come on:
1. Single Page Applications (SPA's)
Nowadays there are several single-page applications out there. The classic example is gmail. These applications are marked by the fact that it has a web-based interface that is extremely interactive and does not have to reload the page, that is, it loads a lot of the application in the first execution and the later executions serve to receive resources needed in certain moments.
I will not discuss the advantages and disadvantages of SPA's, but basically to make a SPA with quality you implement two totally separate things: a graphic interface written with HTML / CSS / Javascript and a web service. The web service consistently exposes all methods to perform the manipulations on the domain that your application needs.
2. WPF applications using MVVM
When you develop an application for windows desktop using WPF it is common for you to want to address this with the default MVVM. A common way then to encapsulate logic for data access in those applications is to use a service. When I worked with this I remember I saw some tutorials and books and were used in the time of WCF services. The reasons are almost the same as the SPA's.
Advantages
With this kind of approach you get some things
Separation of concepts well done: the interface knows the interface, the server knows the domain. Interface changes do not affect the domain, and domain changes do not usually require large interface changes.
The same service can be used for multiple interfaces. If you need to use the same data in a second interface (in a website for example, or in a mobile application), you can request the same service. Again, changing something on the server does not require changing multiple places.
So you can share functionality in a variety of different environments (they only know how to communicate via HTTP in the case of web services), so you can allow the responsibilities of different components that make up your system to be well defined, so you can have ease of maintenance.
Assuming you develop your object-oriented service and you can actually build it with low coupling and high cohesion using the principles of object-orientation and everything. If you need to change the data access logic, it will change in one place on the server and all client applications without any kind of change in your code will benefit from this.
If you change the way a domain type is implemented, the same thing happens. In general, you can reuse a lot of code, allow much more portability and have great flexibility when creating your graphical interface.
For web services, imagine that api.meuservidor.com/clientes/ is a URL that points to a resource that can return a list of clients. When building the interface this is all you need to know to render a list of clients. As clients are deployed, as they are stored, or etc, it is not necessary to know. If you work in a team and there is a programmer responsible for the graphical interface, it will make life a lot easier for him.
In short, implementing the real features of your application that deal with domain types and etc. in a service layer allows you to reduce coupling, increase code reuse, and make your application more maintainable. So, SOA is a methodology, as you said, a style of architecture, which instructs you to have a layer of services in your software to have all these advantages among others.
References
Service-Oriented Architecture - Wikipedia PT
Service-Oriented Architecture (SOA) Definition
