How does Salsa20 work?
The basic building block of salsa20 is a fixed 512 bit permutation. This is similar to a block cipher with a fixed and publicly know key (or a zero bit key if you prefer). Since it has no key input, you can't use it with block cipher modes of operation.
The next step in Salsa20 is a feed-forward by adding the input into the output, turning it into an unkeyed hash function/one-way-function.
If $P(x)$ is a permutation and thus reversible, $P(x)\oplus x$ is one way.
This is the standard way for turning a reversible function into an irreversible one, and is often used to build compression functions.
The input of this 512 bit function gets divided into several parts: A 256 bit key, an 8 byte stream identifier (IV) an 8 byte counter and 16 bytes of fixed padding. Note that the padding is necessary to remove certain symmetries from the raw hash function.
This turns the unkeyed hash into a keyed one, formally a PRF (pseudo random function)
Finally to produce a long output Salsa20 calls the core function with a different counter for each 512 bit block. This is very similar to the CTR mode used with block ciphers.
To address your questions:
2) As such, any cryptographically-robust hash function (one-way only) could be used for CTR encryption?
A generalized counter mode can be used with any PRF, which is the formalization of a keyed hash.
Building a PRF from an unkeyed hash is easy in practice and secure for most hashes we use, such as SHA-2 or SHA-3. Theoretically it's tricky and probably needs the random oracle assumption.
1) If I use Salsa20 in block cipher CTR mode, this property does not seems mandatory to me, am I right?
If you interpret Salsa20 as a 512 bit block cipher it's clearly not secure, since it has a zero bit key and undesirable symmetries on top of that. So you can't use it in CTR mode as it's defined for block ciphers.
On the other hand, the Salsa20 function as described in Step 3 above is believed to be a PRF, and Step 4 is a kind of counter mode, so in a way you're always using Salsa20 in CTR mode.
3) Isn't it easier to design a robust hash than a robust cipher?
Pretty much all hashes we use are built from a permutation, keyed (aka block cipher) or unkeyed. The key idea is that the irreversible operation is where collisions happen, so we want only a single one of those and it should be as far as possible from what the attacker controls.
So I don't think it's easier to build a hash than a permutation or block cipher. In some ways it's harder, since we often request collision resistance from hashes, whereas ciphers are generally used with random keys the attacker has no control over.