As always, "it depends." First, let me clarify the terminology.
Twisted Perspective Broker is basically a system that you can use when you have control over both ends of a distributed action (both with the client and the server). It provides a way to copy objects from one end to the other and call methods on remote objects. Copying involves serializing the object in a format suitable for network transmission, and then transferring it using its proprietary Twisted transfer protocol. This is useful when both ends can use Twisted, and you do not need to interact with non-twisted systems.
Generally speaking, web services are client-server applications that rely on HTTP for communication. The client uses HTTP to request a server that returns a result. Parameters can be encoded, for example. GET or POST or use the data section in a POST request to send, for example, an XML document that describes the action to be taken.
REST is an architectural idea that all resources and operations with resources that the system provides must be directly addressable. Simply put, this means that the URI used to access or manage a resource includes the name of the resource and the operation to execute it. REST can be and is usually implemented as a web service using HTTP.
SOAP is a messaging protocol. It consists of two parts: the choice of several transport methods and one XML-based message format. The transport method can be, for example, HTTP, which makes SOAP a candidate for implementing Wed services. The message format defines all the information about the requested action and the results of the action.
JMS is an API standard for Java messaging systems. It defines some semantics of messages (for example, one-on-one or one-to-many) and includes methods for addressing, creating messages, filling them with parameters and data, sending and receiving and decoding them. The API ensures that it is theoretically possible to change the underlying messaging system without rewriting all your code. However, the implementation of the messaging system does not have to be compatible with the protocol with another JMS messaging system. Therefore, having one JMS system automatically does not mean that you can exchange messages with another JMS system. You probably need to build some kind of bridge service for this, which will be a serious problem, especially when it comes to addressing.
AMQP is trying to improve the situation by establishing a wired protocol to which messaging systems must obey. This means that messaging systems from different vendors can exchange messages.
Finally, SOA is an architecture concept in which applications are split into reusable services. Then these services are combined (“organized”) to implement the application. Each time a new application is created, there is a chance of reusing existing services. SOA is also something that requires non-technical support for reuse to actually occur and services to be developed fairly general. In addition, SOA is one way to start functioning in legacy systems as a complete whole, which can then be expanded and developed using more modern technologies. SOA can be implemented using a variety of technologies, such as web services, messaging systems, or corporate service bus.
You thought about the trade-off between one connection per request and did not open the connection to multiple requests. It depends on the resources available, the messaging template, and the size of your data. If the flow of incoming messages is always the same, then it may be good if the connections remain open, since their number will not change very much. On the other hand, if there are bursts of messages from several systems, then it would be useful to free up resources and not allow connections to linger for too long. In addition, if a large amount of data is transferred to one connection, then the overhead of opening and closing the connection is small compared to the total transaction length. On the other hand, if you send a lot of very small messages, then maintaining an open connection can be useful. The only way to make sure is benchmarking with your specific parameters.
AMQP really can replace the protocol with twisted specifications. This will allow you to interact with a non-twisted system.
Hope this is helpful to you. If you are still wondering about something (and I think you are, since this is such a large area), I would suggest splitting things up into smaller questions and posting them separately. Then the answers may be more accurate.