An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.
The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").
Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853
Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:
- The message grammar validation was incomplete, as mentioned
- The streaming decryption/validation code affected how the packet sequence was processed
- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when
- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)
All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.