And this is one of many reasons why analyses like this provide so much value. It's fascinating that the actual sandbox bypass in this case is so carefully protected. If that sandbox bypass code could be decrypted and reverse-engineered, it could point to the actual vulnerability being exploited, which could then be fixed.
I can already guess without looking that the sandbox is excellent except that oops there's a few edge cases that were MUST FIX, so, we had to cut a small hole in it. The people who understand how difficult this is to do properly built the actual sandbox which will be fine, the ragged hole cut in it (and exploited) was implemented by somebody for whom the sandbox is just another annoying thing they need to work around to get their job done and they don't care that they made it worthless.
I’m sure they care that they spent all that time working around an annoying thing — they don’t want to waste time finding a new workaround when this one is patched. And they’d like to re-use it in other exploit chains, so why not obfuscate it to the best of their ability?
You do highlight an important difference between the mindset of an attacker and a defender. The attacker only needs to be right once, and then they can move onto the next phase of the attack. That’s why they don’t bother “understanding it properly” beyond the perspective of attacking it. A medieval siege unit understands the weak points of castle walls, and how to operate a catapult, but they don’t care about the intricacies of stone masonry beyond what’s necessary for knocking down a wall.
Maybe I was unclear, I think the exploited hole was cut by the vendor.
You hire team A of excellent security people to build you an impenetrable barrier. They do a sterling job and are appropriately rewarded.
Then you realise oops, the new feature we're very proud of can't work with that impenetrable barrier. Hey, Jim, we need the feature to work ASAP, figure out a way to do that without removing the expensive barrier. And so of course Jim cuts a hole in it.