What is the present-day significance of SOAP

REST is indeed an architectural style. SOAP is a data protocol. The distinction is important; you cannot compare them directly.

The primary purpose of REST is to represent resources on the Internet, and to provide mechanisms for discovering them. In contrast, SOAP is used for communicating structured data between computers, and that's all it really does.

Note that you don't actually need REST to create a client/server relationship between two computers on the Internet. All you need is a mechanism that transfers JSON or XML, and you don't even need that if you're willing to be incompatible with everyone else.

Nevertheless, SOAP has fallen out of favor for new, public-facing API's, though it is still commonly used for B2B applications because you can define a "data contract" with it. JSON web services have the virtue of being rather lightweight and flexible, and since Javascript recognizes JSON natively, it's a natural choice for browsers.

But none of that has much to do with REST, really.

Further Reading
Is SOAP still relevant?
Is REST better than SOAP? (good article, even though it incorrectly calls REST a protocol).

REST is much more limited than SOAP, which is its strength and the reason for its popularity.

In SOAP, the set of operations allowed and the set of data types allowed is essentially limitless. SOAP is a remote procedure protocol, which you use to expose local API's across the network without losing any fidelity. This made SOAP popular in enterprise environments where complex transactional systems needed to interact across the network without losing any fidelity along the way. This richness in ability is also SOAP's downfall, because it makes SOAP API's so cumbersome to understand and use that it necessitated automated tooling in the form of WSDL and SOAP client libraries to make sense of things. More so, exposing the full richness of the underlying system is unattractive in public-facing API's, where you want to provide abstractions that let you evolve the underlying system without having to break or version your API.

REST+JSON gained popularity specifically because of its simplicity. It defines a limited set of operations with a limited set of data types, requiring the API designer to carefully design abstractions that fit inside this limited vocabulary and really think through the mapping of business domain to REST resources. A REST API is easy to understand and easy to use without any special tooling. For a public-facing API where your API users may have all levels of skill and knowledge this is exactly what you want, which is why all of the API's you see around the web have been transitioning to REST. SOAP is relegated to enterprise situations where there is still a desire and need to share complex API's between systems. However, with architectural trends towards independently versioned micro-services developed by separate teams even that domain is losing ground.

Essentially, what people have realized is that the set of constraints that you must apply to your API design to make the API simple and abstract enough that it is maintainable and easy to use is exactly the set of constraints that REST introduces, which effectively neutralizes SOAP's benefits leaving you with only its downsides. You could build a simplified API with SOAP, but it would never be as easy to use as REST, so in practice everybody just chooses REST.