I'm not sure if there's anything specific to OpenPGP, but the problem you describe doesn't seem specific to this context.
As far as I'm aware, the exploits that lead to arbitrary code execution (e.g. based on buffer overflows) could happen to the processing of any type of a priori untrusted data that could be processed. Whether it happens in the code that processed a malformed key or any other form of data probably doesn't matter that much in this context.
Whenever you run some code that processes some data that you don't already trust (and in a way that you trust), you want that code to be bug-free, at least free of bugs that would lead to arbitrary code execution or other security problems.
Whether the data is used later by a security mechanism is a secondary concern in this case.
(Of course you also want the implementation of the necessary signature verification to be correct. That's where it matters for security purposes.)
The same type of issue could happen with any X.509-based TLS stack, for example. You'd want the TLS stack not to allow malformed certificates let an attacker get control of your system (again, that's true of any system that process a bunch of bytes it doesn't know in advance). The correct validation and verification of the certificate that will let you trust the TLS connection established once the handshake has completed successfully is very important, but only a secondary matter, then.
I think the main difference compared to other types of data is in the difficulty of implementing this type of code correctly. The storage structures used in the context of PGP or X.509 tend to rely on ASN.1, which can be about as clear as mud in many cases. Writing bug-free code that deals with ASN.1 isn't easy (IMHO).
I think Thomas's quote ("...you should not trust the key server...") had more to do with the fact you can't trust the key server as an entity vouching for the key it serves. This is just a hosting service, as opposed to an editor/publisher/author.