It seems like a stream cipher will always be one-way, whereas a KDF might not be (see AES or DES key schedules for example).
A KDF has nothing to do with DES or AES key schedules. Key schedules are internal functions of the block cipher, they aren't designed to be KDF's. And KDF's are certainly supposed to be one-way functions.
From SP-800 SP 108 chapter 7.1, Cryptographic Strength:
The security strength of a key derivation function is measured by the amount of work required to distinguish the output of the KDF from a truly uniformly distributed bit string of the same length, under the assumption that the key derivation key, $K_I$ [ed: the input keying material], is the only unknown input to the KDF.
So using a KDF might be dangerous if you use it to both derive public and private values.
The output of a KDF should be indistinguishable from random, so this statement is false - which has probably to do with your statement that they may not be one way.
it takes a SALT parameter. So you can use it several times with the same key, but by varying the parameter you will get different output. If you would do that with a stream cipher you would need to remember a state.
Salts are used to further strengthen the security proof for HKDF. In SP 108 they can be part of the Context and are then called a Nonce (and, given that the salt is large enough, random salts are unique in a computational sense). A random IV would do the same thing for a stream cipher.
Salts are not required for key based KDF's as the input keying material should provide enough entropy.
But I think you are mixing up key based KDF's such as HKDF and password based KDF's such as PBKDF - see below.
it has a work factor. So with the SALT and that you can use it as a password hashing function. But then we're kind of off track.
A work factor is only needed if the input material is not strong enough. This is basically the case for password-based KDF's such as PBKDF2, bcrypt, scrypt and Argon2. The work factor is used to strengthen the input keying material (somewhat).
Counter mode encryption doesn't explicitly contain any ways of inputting labels, salts or context. A KDF construction makes these explicit.
With regards to the output, a KDF can be used with different info (label / context) to generate different keys, using the same input keying material. This is important if you integrate such a function in e.g. a HSM (security token), where you want to keep the output as key within the token (instead of splitting it up manually in software).
Finally, many KDF's contain not just expand functions to generate enough output keying material, they also contain extract functionality to compress the entropy in the input keying material. Many stream ciphers require keys that are indistinguishable from random and/or a specific length. So they don't provide extract functionality.
A KDF is build from PRF's; a PRF provides the required security to create proofs for the KDF. Actually, counter mode is often used for KDF's, but they employ a PRF instead of a PRP such as a block cipher (of course the PRF may be created out of a block cipher itself). So in the end many KDF's do output a stream of pseudorandom bits.
