CFB has two advantages over CBC that might have led to its choice.
First, it only requires the underlying cipher to be run in one direction.
Even in the decryption mode, CFB runs the cipher in encryption mode.
This means that you don't need to implement decryption in the cipher.
However I believe that the first ciphers used in PGP, Bassomatic and IDEA,
had both encryption and decryption implementations.
This is more of an advantage with ciphers which have asymmetric speed
in one direction, but I don't think either of those early ciphers had
that property.
The second advantage of CFB relates to block padding. It is easy and
natural in CFB to handle messages which are not a multiple of the cipher
block length (8 bytes for the early ciphers). You simply truncate the
ciphertext so it is the same length as the plaintext, and apply the same
rule in reverse for decryption.
At the time, I don't think we were aware of an analogous technique
for CBC. Most people then (and many now) pad the CBC message to a
multiple of 8 bytes, encrypt, and then remove the padding upon decryption.
Since then we have become aware of the "ciphertext stealing" technique
which lets you truncate CBC messages. But it is a bit complicated, and
does not apply very readily to messages shorter than the block length.
Given these disadvantages, ciphertext stealing is not very widely used
for CBC encryption, rather padding is still used instead.
I think this may have been the reason that Phil chose CFB. As for
the non-standard "sync" operation, I don't remember why he did that.
Probably it just seemed to be a natural way of handling CFB given his
understanding of its rationale in terms of the way it interfaced with
the underlying cipher.
Hal Finney