The flaw with iMessage reference aboved was that it was:
A) Vulnerable to a brute force attack
This was because of a bug discovered by the researchers that allowed a man-in-the-middle-attack to be setup, due to:
- Strict certificate pinning was not used until iOS 9 -- so an attacker could create an impostor certificate and hack DNS on their local network to be able to start intercepting data and begin the attack.
- No MAC is used in the encrypted payload after receiving an ECDSA signature -- thus, the contents of the message/message integrity is not controlled for.
- The signature can then be tampered with or replaced with another signature. See image provided by researchers:
- The "error oracle" compression attack you describe allows one to painstakingly decrypt a message bit-by-bit by taking advantage of how CRC checksums are computed over the original data, but not the AES encrypted payload iMessage then creates.
B) Using a static 64-digit symmetric encryption key for message encryption.
- Rather than use a symmetric key system, an asymmetric system or one utilizing perfect forward secrecy may have been able to prevent this. Once the man in the middle attack was setup, a brute force attack could be launched until, successfully, retrieving the 64-digit key.
Beyond the immediate technical answer, the question as to how this happened is the same for this case as it is for most other commercial, closed-source products; and even many open source packages -- encryption and creating bulletproof cryptosystems is hard. Even given the most valuable company in the world, Apple, with the best engineers and seemingly unlimited resources; mistakes can be and are made.
For more information, I suggest looking at Bruce Schneier's article on the subject, and the researcher's blog post on the subject.