The round-trip latency from point A to a matching engine at point B can be thought of being comprised of two components:
$RTT_{total,A \rightarrow B} = RTT_{network\_transit,A \rightarrow B} + MPL_{matching\_engine,B}$
Where $RTT$ is the round-trip time and $MPL$ is the message processing latency (how long it takes to receive a message and produce an event). The total round trip time, $RTT_{total}$ would be measured from the moment it leaves your network interface (i.e., excluding whatever internal processing day your software may have) to the moment your network interface receives the message indicating the action has been processed. You might find my other answer regarding latency informative: HFT - How to define and measure latency?.
Now, with respect to $RTT_{total}$: when communicating with an exchange in an different data center transit latency will almost always dominate. Matching engines are very fast, but moving packets can be relatively slow in comparison. For example, from Carteret (where NASDAQ hosts their matching engines) to Mahwah (where NYSE hosts theirs) is approximately 45 miles (rough measurement from Google Maps). The best case round-trip transit latency is about 500$us$ (approximately 250$us$ one way), but this is not achievable due to frictions related to network transit: (1) fiber doesn't run as the crow flies; (2) switches and routers add latency along the way; and, (3) packets don't travel at the speed of light through fiber (I believe it is about 70% of $c$).
Now, Mahwah and Carteret are the two extreme cases as they are the two data centers furtherest away from each other. The BATS data center is located in Weehawken at NY5. This data center is about at the half-way point between Mahwah and Carteret so you would be looking at a best-case (unachievable) round-trip latency of about 250$us$.
Transit latency is also the only component directly under the control of the participant. $MPL_{matching\_engine}$ is largely a constant for all participants (although, not always due to matching engine architecture and loading of order entry gateways). $RTT_{network\_transit}$, on the other hand, can be manipulated by reducing 2 of the 3 frictions above. The revelation made in "Flash Boys" was well known throughout The Street (it seems Brad and the IEX guys were somewhat late to the party): there was a lot of low-hanging fruit in minimizing the impact of the first friction: the path that the fiber takes. By doing this savvy participants can be closer on a relative-basis to other matching engines even if they are located directly next to their competitors in real-space.
Remember, this discussion is almost exclusively limited to cross-data center messaging. There is very little ability to minimize the impact of $RTT_{network\_transit}$ within a single data center because: (1) the length of fiber interconnects are largely normalized for all cross-connected participants; and, (2) there are very few network elements between participant and matching engine. This means that internal latency to a specific participant is the most important (in other words, faster software).
All that being said, to answer your question specifically is not something many folks will do as latency numbers are held close to the vest. However, the reason for all of the above is to demonstrate to you that you can easily estimate it by simply estimating $RTT_{network\_transit}$. I think you'll find that, for example, $RTT_{total,NASDAQ \rightarrow ARCA}$ is going to be between 600$us$ and 1.5$ms$ assuming that packets travel through fiber at $0.7c$ and then depending on what penalty you want to add for the path of the fiber.
