Thanks for your insights and questions, very useful!
Some of your questions I think will be answered with the data I'm presenting, but I can give you a summary here as well. Yes, those large variations in latency *roughly* match what I've seen in my testing (avg latency of 19ms, variation of +/- ~14ms), which uses a different chip (CC2540) as well as different firmware (of course). As to the cause, the testing I'm doing tries to isolate and measure ONLY the BLE aspect (I'm not doing note-to-audio latency testing), and I see similar (although slightly better) numbers, so I suspect that's (the BLE transport) where it's coming from.
With regards to robustness, I agree that the notification mechanism at first glance might seem unreliable and hence need some form of journaling (such as RTP-MIDI, as you point out). And, the results I've gathered certainly do not rule out the possibility of needing to implement something like that, and we might need to in the future.
However, in experimental tests with large (>100000) numbers of packets, I've observed a 0% error rate using notifications from device->iPad, provided the data rate is not unreasonable. (e.g. a data rate (assuming 3 byte MIDI packets) of 100hz or less). This, plus successful results of "burst" tests makes me not TOO worried about needing a more complex journaling protocol, at least, not for now.
I agree with your reasoning regarding the connection interval on the iOS device, I think that's the source of the latency/jitter as well. Making the device be "master" and the iPad be a "slave" is a very interesting idea, it had not occurred to us... and certainly worthy of more study and research! Though I doubt I'll be able to do so before my flight in a few hours ;), I'll look into this for the future. (probably after the conference)