It's quite simple really. This is a service, not a standalone application. Therefore they need to block the leaked build so it does not impact legitimate users. Still, I'd imagine redirecting IP traffic, changing a DNS name and a few small fixes should suffice and not cause a significant delay... If the traffic is encrypted, a simple revocation of a crypto key should suffice even.
When you make an application with 8 million current users, you always have the power to take on 10. When you open it up to over 200million additional customers, you should account for at least 50m, but if there is a pirate copy out there that means that one user takes up two or five worth of bandwidth, suddenly your previous capacity ot take on 42million new customers is reduced to taking on 8.5m new customers, far too little.
It's also incredibly likely that a pre-release system uses 5 or more times the bandwidth, as the debug data has to be communicated somehow and modifying the phone itself to JTAG or display debug data has the potential to hide, disguise, or entirely bypass the source of the bug or the bug itself.
If you have a number of closed platforms to test the hardware on, the last thing you should do is modify the test platform to record the data. No, you should have the data remotely forwarded to another source via a commonly used data route. With PCs it used to be Serial Ports, and now it's sometimes Ethernet sometimes USB. With a phone it has to be wireless, bluetooth or USB, and I suppose they chose wireless to-the-server debugging.