Latency of reading from a large array of i2c slaves?
You're missing the part where slaves can do what is called clock stretching by holding the clock line for as long as they need to get ready.

So, without looking into the datasheet of each of your sensors, this will be impossible to answer.

However, many I²C devices simply don't do clock stretching, so your calculation might work out, if you add a bit of pause just to be sure everyone on the bus noticed the stop condition.

64 I²C slaves smells a lot like address collision (many I²C device types come with a fixed address, or maybe a set of 8 selectable addresses) – it might, very well, be possible that a different, possibly hierarchical bus architectures with microcontrollers polling "their" sensors and then communicating the "aggregate" data to the main MCU is much cleaner to handle. Especially considering that I²C is an externally pulled-up bus, and ensuring this works well with a 64-device bus is not really inherently trivial.

Edit: turns out each of your sensor is a microcontroller anyway. 

Then, why not simply make a giant array of shift registers? SPI units are typically designed for exactly that purpose, and have shift registers internally. That way, you can make a daisy-chain of SPI devices, and save yourself the addressing overhead.