SOAP is designed to be abstract enough to use other transports besides HTTP. That means, among other things, that it does not take advantage of certain aspects of HTTP (mostly RESTful usage of URLs and methods, e.g. PUT /customers/1234 or GET /customers/1234).
SOAP also bypasses existing TCP/IP mechanisms for the same reason – to be transport-independent. Again, this means it can’t take advantage of the transport, such as sequence management, flow control, service discovery (e.g. accept()ing a connection on a well-known port means the service exists), etc.
SOAP uses XML for all of its serialization – while that means that data is “universally readable” with just an XML parser, it introduces so much boilerplate that you really need a SOAP parser in order to function efficiently. And at that point, you (as a software consumer) have lost the benefit of XML anyways; who cares what the payload looks like over the wire if you need libSOAP to handle it anyways.
SOAP requires WSDL in order to describe interfaces. The WSDL itself isn’t a problem, but it tends to be advertised as much more “dynamic” than it really is. In many cases, a single WSDL is created, and producer/consumer code is auto-generated from that, and it never changes. Overall, that requires a lot of tooling around without actually solving the original problem (how to communicate between different servers) any better. And since most SOAP services run over HTTP, the original problem was already mostly solved to begin with.