Not sure how this changes the facts—that ASN.1 is a niche language used in a few narrow areas, that it doesn't get a lot of attention because only a tiny percentage of engineers understand or use it, and that we'd all be better off if everyone just used more sensible data formats, such as JSON, XML property lists, or any number of other similar formats that are well understood, broadly used, and thus thoroughly debugged. The same is true for all the usual binary formats that people define using ASN.1 (BER, DER, etc.), but doubly true for the ASN.1 format itself.
If they're really passing the actual ASN.1 syntax data around over an insecure channel and providing a compiler that compiles the abstract syntax into a new parser to parse a data stream... that's just a recipe for failure in every possible way. Such a design means taking ASN.1 compiler code that most people assume will be used only by software engineers in a controlled setting, and deploying it in such a way that communication equipment all around the world has to use it on the fly to create executable code and run it. Such a design precludes code signing, because the device has to be able to run unsigned, freshly generated parser code derived from the ASN.1. This means that the security of the device is weakened fundamentally, and any security holes in either the ASN.1 compiler or in the resulting parsers are likely to be easier to exploit as a result.
More importantly, it means that arbitrary third parties can create parsers and then provide incompatible data to feed to those parsers, maximizing the chances that there will be an exploitable bug in those parsers that can result in privilege escalation.
ASN.1 should die already, and so should all of the various binary encodings derived from it. IMO, they're fundamentally bad for security, they're hard to audit, and when used in dangerous ways like this, they represent a major security risk.