Getting access to the privileged 'crosh' extension in this exploit depends on getting code into its process, which depends on the odd choice to put unrelated extensions into a shared extension process when there's too many processes. Given the insecure nature of the Chrome App Store, this was questionable to begin with - should a potentially backdoored bookmarking extension really share a process with my password safe? - but once privileged Chrome OS code started running in extension processes this immediately became a huge security hole waiting to be exploited.
In this case they also don't even need a compromised extension, because they can (if I understand this right) impersonate an extension's frame and then send messages of their choice to the extension. The access control here is almost entirely done inside the content process, where potentially compromised content is running. It's hard to avoid this since most extension code runs inside content processes by design, but it's a weakness that is rarely (if ever) called out in the chrome extension documentation.
The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++.
The parts of the chain after getting access to crosh also seem like tough-to-avoid oversights. This set of attacks definitely make symlinks look like a problem child, given how useful they are for all sorts of naughty behavior the attack gets up to :)