Can I achieve data authentication with ChaCha20 without MAC? My case is rather special. I need to send data in small chunks, each under 32bytes. ChaCha20 state is 64 bytes.

Since I will be receiving data stream in chunks, id like to verify it on the fly (i.e. after I receive each chunk, make sure it was not tempered with). 

Using MAC is a bad choice, as I'd have to compute MAC every time I send my 32byte chunk and append it to the message. And I don't think this is a standard approach as with Poly1305, where as I understand, you compute MAC only once when ALL the data is transferred, not sending intermediate MACs.

So I got this idea: instead of computing MAC (with Poly1305 or other), why not just use the 32byte data twice, make a 64byte chunk that can be XORed with one state of ChaCha20.

Upon deciphering, I verify that the first 32 bytes are equal to the latter 32 bytes. If yes, there was no modification. If no, there was some tampering / transmission errors.

So my questions are:

1. Does repeating ciphertext twice compromise security of the stream cipher? (Assume attacker knows this)

2. Is there some standard way how to provide message authentication with stream ciphers without this "hack"?

Thanks for answers and opinions!
You're in luck!  According to your question, you have 64 bytes of bandwidth per 32-byte message available.  The authenticated cipher crypto_secretbox_xsalsa20poly1305 has a ciphertext expansion of only 16 bytes—that is, the ciphertext is only 16 bytes longer than its plaintext, no matter how long the plaintext is, so in this case it will use only 48 bytes and leave you 16 bytes under budget!

Just use crypto_secretbox_xsalsa20poly1305 for each 32-byte message before you act on it—if you use NaCl/libsodium, you won't even be allowed to get at the decrypted plaintext if it's a forgery—and you'll be good to go.

If you already have a message sequence number, use that as the crypto_secretbox_xsalsa20poly1305 nonce; if not, you can use 8 of the remaining 16 bytes available to you for a message sequence number.  If you ever repeat a nonce with the same key, the security vanishes.

No need to worry about stream ciphers (which can fail to protect confidentiality if you act on forged messages), MACs (which don't protect confidentiality at all), HMACs (which are a specific kind of MAC), etc.  Focus on authenticated ciphers like crypto_secretbox_xsalsa20poly1305 or AES-GCM.