As D.W. notes, the distinction made between "bit-based" and "word-based" stream ciphers in the source you cite is irrelevant to the end-user. For both kinds of stream ciphers (as well as for block ciphers in streaming modes like CTR or OFB), the manner in which the keystream is combined with the plaintext is always the same: bitwise XOR, which operates at the bit level but is easily parallelized both in hardware and in software.
In any case, the actual distinction they seem to be making is between LFSR-based stream ciphers, which sequentially output one bit per iteration, and ciphers such as RC4 (and, presumably, block ciphers in streaming modes) which generate their output bitstream in larger chunks.
LFSR-based stream ciphers have generally been designed for direct hardware implementation, where they have the advantage of simplicity, but they've traditionally suffered from poor performance in software; whereas in hardware it's easy to shuffle single bits around and combine them using simple logic gates, typical CPUs are designed for carrying out higher-level operations on chunks of 8, 16, 32, 64 or 128 bits in parallel. Running a cipher that operates on single bits in software thus wastes most of the CPU's power, unless the algorithm can be reformulated to operate on many bits in parallel, something that many older LFSR-based cipher designs haven't been very well suited for.
On the other hand, ciphers like RC4 were designed for software implementation from the beginning, and do very well there. (Although RC4 itself operates on 8-bit bytes, which is arguably suboptimal for modern high-end CPUs, its simplicity still keeps is competitive there. Besides, there are still plenty of 8-bit processors around in embedded devices and such.) However, they often make use of features that are difficult and costly to implement in hardware, such as access to relatively large amounts of RAM (e.g. 258 bytes for RC4, accessed in an essentially random order).
In recent years, though, the trend in stream cipher design has been towards ciphers that blur these lines, being efficient to implement in both hardware and software. Good examples can be found e.g. in the eSTREAM portfolio: the Trivium cipher, for example, is fundamentally a "bit-based" shift register design, and can indeed be implemented as such if desired; however, it is designed such that up to 64 bits of the output can be computed in parallel, which allows very efficient software implementations using any word length of up to 64 bits. (Conveniently, the same parallelizability also allows Trivium to be made very fast in hardware, by essentially duplicating the circuitry up to 64 times, as long as available space permits this.)