That's more untrue that true. Most popular applications of AES could just as easily use CTR instead of CBC (I'm not particularly interested in litigating the conversion of applications that use ECB); many of those applications even have an option to do that. Most settings in which AES-CTR is acceptable admit to any other stream cipher.

Even most message-based crypto --- applications where the designers can predict the size of most encrypted messages --- are well served by CTR, or by a native stream cipher.

So, while there are fundamental differences between Salsa20 and AES, for bulk encryption purposes those differences come nowhere close to the difference between GCC and Windows 8. It's really more of a "GCC vs. LLVM" kind of difference.

In addition to what others said, there's even fewer differences between them internally.

Salsa20 <stream cipher> is not a "traditional" stream cipher -- basically it's Salsa20 <hash function> (not collision resistant) in counter mode. The hash function itself is implemented as permutation with final addition of input words to make it irreversible. With this permutation you can build a block cipher, and by the way that's what SHA-3 finalist BLAKE does by introducing addition of key words during rounds (except it's built on a variant of Salsa20 called ChaCha20).

(I'm not saying that you should build your own block cipher from Salsa20, of course :)

The original sentence, though, is:

try Salsa20 rather than AES and Poly1305 rather than GCM.

AES-GCM is also not a "block cipher".

For those playing along at home, AES-GCM is AES in CTR mode plus a variant of Wegman-Carter MAC function to authenticate the data.

CTR mode turns block ciphers into stream ciphers, and the best way to use AES is in CTR mode.

That's a stretch.