Whether this is OK depends upon the details of the encryption algorithm. You are right to point this out as "a fishy smell". That said, depending upon the details, it's possible GnuPG's approach could be OK. For instance, if the encryption algorithm it uses is IND-CCA2 secure, it might be fine.
Apparently Moxie Marlinspike's advice is focused on MACs (the symmetric-key setting), but I think you are right that it is also good advice in the asymmetric-key setting as well. However, let me point out one small detail. In principle there's no difference between a MAC (symmetric-key) vs signature (asymmetric-key). In practice there is one difference: it is rare to find symmetric-key encryption algorithms that are already secure against chosen-ciphertext attacks (without a MAC), whereas it's more common to find asymmetric-key encryption algorithms that are already secure against chosen-ciphertext attacks (without a MAC). In other words, most symmetric-key encryption algorithms are IND-CPA secure but not IND-CCA2 secure. In contrast, many asymmetric-key encryption algorithms are IND-CCA2 secure (and using one that isn't IND-CCA2 secure is also a "fishy smell").
If GnuPG uses an IND-CCA2 secure asymmetric-key, the risks that Moxie Marlinspike was pointing out don't apply: he was pointing out the risk of chosen-ciphertext attack on the decryption routine, but any IND-CCA2 algorithm is already secure against chosen-ciphertext attacks, even in the absence of any signature.
You can view the process of MACing or signing the ciphertext as a way of defending the encryption scheme against chosen-ciphertext attacks (i.e., defending an encryption scheme that isn't IND-CCA2-secure against IND-CCA2-style attacks). If the encryption scheme is already IND-CCA2-secure, that reduces the need to sign/MAC the ciphertext.