You're right — the autokey cipher described in the Wikipedia article is not self-synchronizing, since an error in one ciphertext letter will propagate through the decryption process into every $n$-th following plaintext letter, where $n$ is the key length.
There are variants of the autokey cipher sometimes found in crypto puzzles that are self-synchronizing, e.g. where the ciphertext (rather than the plaintext) is used to extend the key, but those variants are trivially insecure (even by the standards of classical ciphers): as long as the encryption method used is known, all but the very beginning of the ciphertext can be straightforwardly decrypted without knowing anything about the key except its length!
Fundamentally, this is because the key in an autokey cipher is only used to start the decryption process, and is not explicitly involved in later stages of the process. If the decryption process did not propagate errors in the key (or in the extended keystream) forward indefinitely, the decrypted plaintext would eventually become entirely independent of the key — and, indeed, would do so at the same time or before it becomes independent of errors in the beginning of the ciphertext, which is what's required for self-synchronization.
The reason why CFB mode decryption can be secure while being self-synchronizing is that each plaintext symbol (bit / byte / etc., depending on the CFB variant used) is calculated based on the corresponding ciphertext symbol, a limited number of previous ciphertext symbols and the secret key. It's this continuous perturbation of the decryption process by the key that prevents an attacker from decrypting any part of the ciphertext without knowing the key, while still allowing the legitimate recipient (who does know the key) to resume decryption after an error in the ciphertext.
Anyway, self-synchronization isn't really considered a particularly useful property nowadays. Honestly, I'm not convinced that it ever really was, except as an ad-hoc justification for the existence of CFB mode.
Generally, we do want an encryption scheme to detect errors in the ciphertext (and, in particular, any malicious modifications made by an MITM attacker), which is why one should use an authenticated encryption mode. But recovering partially correct plaintext from corrupted ciphertext, like CFB mode does, is much less useful.
If you do want an encrypted communications protocol that is error-tolerant, it's much better to apply a non-cryptographic error correction scheme on top of the encryption (and authentication) layer, so that you can recover the entire original ciphertext (and thus the plaintext) even from a partially garbled message, and/or to divide long data streams into discrete packets and encrypt and transmit them independently (possibly with some retransmission mechanism in case of packet loss).