The way their DR is setup is that clients of NYSE (brokerages, OTC systems, firms, banks) all have IP (not dns) connections to the primary NYSE production datacenter and a full second set of IPs for the DR site. It's not a "dns and load balancers" setup where the service itself can just route the traffic somewhere else. The clients themselves determine where to connect to consume trade data and execute trades. There is likely some modus operandi given to clients on how to connect to primary and DR sites based on some specific logic.
The NYSE DR guide [1] says that if DR is active, production is not. It's not a distant reach to consider that some of these clients have a deadman switch doing a healthcheck poll on DR and switching to it when it see's that it is "up". If they've built their systems in such a way that when it detects the DR site active it uses that, then it makes sense that having both "online" would cause some havoc. I'm sure the complexity of the entire exchange is fairly significant, and having "two" copies of it running in parallel with both able to accept and execute trades would be a scenario that can cause some unintended consequences. Fundamentally, an exchange is "atomic" and transactional and cannot be meaningfully distributed to two sites that are that far away. The replication in place is likely master/slave with a switch to make the slave primary. Anyone who has toyed with master-master replication on less complicated databases knows the issues that can come up with split writes. Imagine that at the scale of a system as large as the NYSE.
[1] https://www.nyse.com/publicdocs/support/DisasterRecoveryFAQs...