一如既往，“视情况而定”。首先，让我们理清术语。
Twisted 的 Perspective Broker 基本上是一个您可以在控制分布式操作的两端（客户端和服务器端）时使用的系统。它提供了一种将对象从一端复制到另一端并在远程对象上调用方法的方法。复制涉及将对象序列化为适合网络传输的格式，然后使用 Twisted 自己的传输协议进行传输。这在两端都可以使用 Twisted 并且您不需要与非 Twisted 系统交互时很有用。
一般来说，Web 服务 是依赖 HTTP 进行通信的客户端-服务器应用程序。客户端使用 HTTP 向服务器发出请求，服务器返回结果。参数可以编码为例如。 GET 或 POST 请求，或使用 POST 请求中的数据部分来发送，例如，描述要采取的操作的 XML 格式的文档。
REST 是一种架构理念，即系统公开的所有资源和对资源的操作都应该是可直接寻址的。简单地说，就是用于访问或操作资源的 URI 包括资源名称和对其进行的操作。 REST 可以并且通常被实现为使用 HTTP 的 Web 服务。
SOAP 是一种用于消息交换的协议。它由两部分组成：多种传输方法的选择，以及单一的基于 XML 的消息格式。例如，传输方法可以是 HTTP，它使 SOAP 成为实现 Wed 服务的候选者。消息格式指定有关请求的操作和操作结果的所有详细信息。
JMS 是基于 Java 的消息传递系统的 API 标准。它为消息定义了一些语义（例如一对一或一对多），并包括寻址、创建消息、用参数和数据填充它们、发送它们以及接收和解码它们的方法。该 API 确保您可以在理论上更改底层消息传递系统的实现，而无需重写所有代码。但是，消息系统实现不需要与另一个启用 JMS 的消息系统协议兼容。因此，拥有一个 JMS 系统并不意味着您可以与另一个 JMS 系统交换消息。您可能需要构建某种桥接服务才能使其正常工作，这将是一个重大挑战，尤其是在解决问题时。
AMQP 试图通过定义消息传递系统必须遵守的有线协议来改善这种情况。这意味着来自不同供应商的消息传递系统可以交换消息。
最后，SOA 是一种架构概念，其中应用程序被分解为可重用的服务。然后将这些服务组合（“编排”）以实现应用程序。每次创建新应用程序时，都有机会重用现有服务。 SOA 也是需要非技术支持活动的东西，这样才能真正实现重用，并且服务被设计得足够通用。此外，SOA 是将遗留系统中的功能打包成一个有意义的整体的一种方式，然后可以使用更现代的技术进一步扩展和开发。 SOA 可以使用多种技术实现，例如 Web 服务、消息传递系统或企业服务总线。
您考虑了在每个请求一个连接和为多个请求保持连接打开之间的权衡。这取决于可用资源、消息传递模式和数据大小。如果传入的消息流始终相同，那么让连接保持打开状态就可以了，因为它们的数量不会发生太大变化。另一方面，如果有来自多个系统的消息突发，那么释放资源并且不要让连接停留太久可能会很有用。此外，如果每个连接传输大量数据，那么与总事务长度相比，打开和关闭连接的开销很小。另一方面，如果您传输大量非常小的消息，那么保持连接打开可能是有益的。使用您的特定参数进行基准测试是确定的唯一方法。
AMQP 确实可以替代 Twisted 特定的协议。这将允许与非 Twisted 系统进行交互。
我希望这对你有用。如果您仍然对某事感到疑惑（我认为您是，因为这是一个很大的区域），那么我建议您将问题拆分为较小的问题并单独发布。答案会更准确。