The term architectural style moved out of the research literature and into the lexicon on practitioners after the Fielding thesis positioned Representational State Transfer (or REST) as the architectural style of the Web. I've always been hesitant to adopt this line of thinking because REST struck me as more of a philosophy -- and a not-quite-accurate description of how the Web works in practice. Now a-days its popular, at least on blogs, to call SOA an architectural style, sometimes coupled with a statement to the effect: Yeah, and we've been doing this for years with [insert your favorite middleware framework here]. I think this misses the point somewhat radically as I'll explain below.
The second related tendency I've seen is the claim that Web services are an instance of this architectural style. I don't think either claim is right, but I'll dispense with the latter first: Web services can be used without reference or respect to any stable model. The beauty of Web services is their use to support SOA, but they can certainly be used for straightforward client server modeling as well. I happen to prefer vanilla HTTP for this kind of interaction, with POX payloads where required (its not just for AJAX), but Web services will work, especially since there is reasonable tooling available to make this pain free for developers.
The problem with the claim that SOA is just an architectural style is that it reduces SOA to an abstract model, when what most people are trying to convey is a new (or at least evolutionary) approach to organizing the data-center. This approach involves, among other things, business-contract driven services, centralized and managed policy enforcement, leveraging ubiquitous Web protocols, process-oriented modeling, etc. Only one of those listed items is technology oriented, but it has clear business benefits as well.
SOA is the tag we wound up with, but perhaps its not so accurate. If I had to come up with something of my own, it would probably be Rationalized Business-Oriented Data Center Organization Amenable to Process Orchestration For Agility and Value. Somehow I don't think RBODCOATPOFAV is going to catch on like wildfire. (But you never know, so if it does, you read it here first!)
But what I want to suggest is that what we're really talking about is a way to better organize software assets to achieve business goals. And this is not what people mean by an architectural style at all. Now you might say this is a chicken or the egg problem. Don't we need to understand the architectural style that supports this before we can talk about serving business needs effectively? In my opinion, the answer is no. I think we will be doing ourselves a tremendous disservice if the SOA tech stack is not driven from the business needs down. The tendency to develop bottom up technologies with the idea that the interests and insights of middleware software folks will solve the needs of business is flawed. We've had a generation of distributed object middleware that suggests as much. And in fact it wasn't even that good for techie solutions.
I'm very interested in qualifying this problem but I think it will take some time to reach a broad consensus among all interested parties. In the meantime, you'll see terms like SOA 2.0 emerging precisely because people are trying to find a way to force the discourse away from the discontinuities that exist today. Long time associates know I have a morbid interest in semiotics: to me, this is an attempt to align an understanding between sign, signifier and signified that does not have stability today. And the quest for clear meaning is a good thing.