I have been working with SOAP and REST for a while, I can tell you that both have adv/dis. But, instead of enumerating over those, I will try to give my reasons and scenarios in which I will choose one over the other.

REST

1. If services will be consumed by a web browser internet application, mobile application (when processing power is 'low') I will choose REST, as the communication is being made in json format which is more friendly with javascript technologies and the processing and parsing time is less than XML.
2. When services will expose the data as part of a simple API giving access to the user to do CRUD operations, or when not much business logic is involved in the processes. I will choose REST too if I have to build a public API.
3. If time is in play, implementation of REST is simpler than SOAP. As there are no standards you don't need to have contracts. There are some best practices, but at the end you could use HTTP verbs as you want and create URI style in the way you prefer, but having this much flexibility will make you at some point start doing a kind of RPC API instead of a resource API (remeber REST is more about resources).
4. Take advantage of cache provide by http GET verb in browsers, if the purpose of your service is expose information on web page app.
5. From a developer's perspective, which is always important, it is faster to build these kind of services. You just need to know a framework that supports REST, such as JAX-RS, Spring REST, Jersey, and some notions of JSON. The learning curve is also smaller.
6. It is a lightweight form of transport information, and it is faster as it doesn't require extensive processing.

SOAP

1. Have contracts that defines the communication within the services, you will be tied to this contract and your clients must follow it too. Any change in this contract will impact all your clients. You must always document what contracts you must use for your operations.
2. Have interesting standards that can work in the system integration as WS-Interoperability, WS-addressing, WS-security, so basically is a technology that have several standards which makes easier the phase of agreement, not always the implementation.
3. Can be used with different transport layer smtp, http, if you want to have different kind of clients.
4. Good standard to transport binary data MTOM/XOP or SwA. If prefer this one to send the bytes in the body of a PUT request.
5. Better definition of security and integrity, a lot of options comming from the standards, normally the more used in REST is OAuth.
6. From the developer perspective this will take more time to learn and also you need to have at least very basic knowledge of XSD, XPath, WSDL and other concepts. In some situations following the standards is not always easy. You have good tools and frameworks to build them JAX/WS, Spring-ws, CXF.

Answering your question and thinking in a small/medium company trying to standardize the IT infrastructure, I would choose SOAP as it has more mature tool support in all areas. Personally, I like SOAP:fault messages, the RPC style for business operations that SOAP offers. Assuming that your microservices are not related to a specific field, I think have some kind of ESB could help you in managing the entire infrastructure and set your business rules. On occasion, people may think SOAP is over-engineering the solution. But, I go with the idea as it is a standard that has been in the market for a while.

https://stackoverflow.com/questions/32534401/soa-microservices-use-api-rest-or-soap