Actually, s is in CFB mode to handle transmission channels for the encrypted data that can add or drop individual bytes.
In the olden times (say, the 70's), it was common to transmit data over serial channels, for example, RS-232. These channels were not perfect, and one common error we see is that if the transmitter sent 7 bytes, the receiver might get only 6 (or possibly 8); this would happen only on occasion, but it was a definite possibility.
Now, consider what would happen if we sent CBC-encrypted data over such a channel. The first time we drop a byte, what would happen is that the block boundaries that the encryptor and the decryptor assume would not line up; what the encryptor thought was the first byte of the next block, the decryptor would assume is the last byte of the previous block. The decryptor would get gibberish, and (this is the important point) there is no mechanism for them to ever resync.
That is what s in CFB mode is for; if we set s=8, then after a drop (or add) error, the decryptor will get the next 8 bytes (8 assuming DES; this is the 70's after all) as gibberish, but then it will start to decrypt correctly (assuming, of course, that the transmission channel doesn't give us any more errors).
Now, times have changed; we don't deal with such channels that much any more. In addition, we are considerably more sensitive to what an active attacker could do; if we did need to deal with such a channel, we're more likely to break up the plaintext stream into a series of records, encrypt (and MAC) each record separately, and insert a noncryptographical resyncing protocol (e.g. byte-stuffing in end-of-record markers) on top of it. That way, an error may cause us not to receive a record or two, but nothing more (and the attacker could not introduce any bogus data).
As for the s parameter in OFB mode, that is universally recognized as a bad idea; using an s < n vastly increases the probability of OFB falling into a short loop, with no benefit in compensation.
