A method called cipher feedback (CFB) is used in OpenPGP to prevent data leakage and modification. It seems appropriate here to discuss the advantages of this method.
OpenPGP, like most other systems, uses a something called a block cipher to encrypt things. You start with a fixed block of data (usually 16 bytes), run it through the block cipher encryption function, and end up with an encrypted block of data of the same length. To get back the original data you run the encrypted block through the block cipher decryption function.
It is very possible that you have more than 16 bytes of data to encrypt. You could just apply the encryption function in sequence to each block until you run out of data1). For decryption you would just apply the decryption function to each block in sequence. This method, although simple, has some weaknesses.
If an attacker has some idea what is encrypted in the blocks they might be able to shuffle/duplicate/delete them in a way that might mislead you after they are decrypted. Because all the blocks with the same data will encrypt to the same value, an attacker might be able to see patterns that might give them some idea of what that data is.
CFB (the thing that OpenPGP does) is a method that overcomes these shortcomings. Instead of encrypting the block you instead encrypt the last encrypted value, add the block in, and use this as the next encrypted value. Very simple.
Patterns in the encrypted output are eliminated. Since CFB uses the popular technique of adding in the block to make the encrypted value it is possible to flip bits in the eventual unencrypted output. CFB imposes a cost to such modification however. Even a single bit flipped in a block will result in the entire next block coming out as random garbage. Attempts to shuffle/duplicate/delete the blocks will cause such random garbage at the edges of the modified areas. Attacks must work around this garbage and the corresponding lost data. As a result such attacks are significantly more difficult.
CFB has some desirable secondary characteristics:
CFB uses the encryption function for both encryption and decryption2). That simplifies things somewhat.
CFB is self synchronizing. Corrupt or missing blocks will cause the next block to be random garbage but the following and subsequent data will be decrypted properly. This is consistent with the principle that encryption should not destroy access to good data.
CFB requires no extra complication when the data does not completely fill the last block. It just works.
The protection provided by CFB is intrinsic. It becomes an essential part of the protocol. If it is implemented incorrectly it will not interoperate with correct implementations. Contrast this with schemes that only check for modification and do nothing to prevent it in the first place3).
OpenPGP has multiple implementations in common use. So a user of OpenPGP can be sure of CFB protection. The user of a system that merely checks for modification can not be entirely sure that the check is currently protective. Message modification is very rare. A broken check might not be noticed for a long time.
The EFAIL venerability is an excellent example of this. It involved the modification of OpenPGP formatted messages. It turned out that some email clients were sending these modified messages to an an interpreter that leaked data (HTML) after decrypting them. The clients in question were ignoring the OpenPGP provided modification check (MDC). CFB contributed significantly to the difficulty and impracticality of the attack.