As always, "it depends". First, let's clear up the terminology.
Twisted's Perspective Broker basically is a system you can use when you have control over both ends of a distributed action (both client and server ends). It provides a way to copy objects from one end to the other and to call methods on remote objects. Copying involves serialising the object to a format suitable for network transfer, and then transferring it using Twisted's own transfer protocol. This is useful when both ends can use Twisted, and you don't need to interface with non-Twisted systems.
Generally speaking, Web Services are client-server applications that rely on HTTP for communication. The client uses HTTP to make a request to the server, which returns a result. Parameters can be encoded in eg. GET or POST requests or use a data section in a POST request to send, for example, an XML-formatted document that describes the action to be taken.
REST is the architectural idea that all resources and operations on resources that a system exposes should be directly addressable. To put it somewhat simply, it means that the URI used to access or manipulate the resource includes the resource name and the operation to carry out on it. REST can be and commonly is implemented as a Web Service using HTTP.
SOAP is a protocol for message exchange. It consists of two parts: a choice of several transport methods, and a single XML-based message format. The transport method can be, for example, HTTP, which makes SOAP a candidate for implementing Wed Services. The message format specifies all details about the requested action and the result of the action.
JMS is an API standard for Java-based messaging systems. It defines some semantics for messages (such as one-to-one or one-to-many) and includes methods for addressing, creating messages, populating them with parameters and data, sending them, and receiving and decoding them. The API makes sure that you can, in theory, change the underlying messaging system implementation without having to rewrite all of your code. However, the message system implementation doesn't need to be protocol-compatible with another JMS-enabled messaging system. So having one JMS system doesn't automatically mean that you can exchange messages with another JMS system. You probably need to build some kind of bridge service for that to work, which is going to be a major challenge especially when it comes to addressing.
AMQP attempts to improve the situation by defining a wire protocol that messaging systems must obey. This means that messaging systems from different vendors can exchange messages.
Finally, SOA is an architecture concept where applications are broken down into reusable services. These services are then combined ("orchestrated") to implement the application. Each time a new application is made, there is a chance of reusing the existing services. SOA is also something that requires non-technical support activities so that the reuse really happens and services are designed to be general enough. Also, SOA is one way of starting to package functionality in legacy systems into a meaningful whole that can then be extended and developed further using more modern techniques. SOA can be implemented using a variety of technologies, such as Web Services, messaging systems, or an Enterprise Service Bus.
You pondered the tradeoff between one connection per request and keeping the connection open for multiple requests. This depends on available resources, the messaging pattern, and the size of your data. If the incoming message stream is constantly the same, then it could be fine to let connections stay open since their amount won't change very much. On the other hand, if there are bursts of messages from several systems, then it could be useful to release resources and not let connections linger for too long. Also, if lots of data is transferred per connection, then the overhead of opening and closing the connection is small compared to the total transaction length. On the other hand, if you transfer lots of very small messages, then keeping the connection open could prove beneficial. Benchmarking with your particular parameters is the only way to be sure.
AMQP could indeed replace the Twisted-specific protocol. This would allow interacting with a non-Twisted system.
I hope this proves useful to you. If you're still wondering about something (and I think you are, since this is such a large area) then I would suggest splitting things into smaller questions and posting them individually. The answers can then be more precise.