Why not use chacha derivatives (BLAKE, rumba) to make an [H]MAC for use with chacha? Why use poly1305?
Performance.
Poly1305 is extremely cheap to compute, and the computation can be essentially arbitrarily parallelized, because it's just evaluating a polynomial modulo $2^{130} - 5$.
In contrast, functions like BLAKE2 and Rumba20 can't be parallelized without changing what it is they compute: the parallel BLAKE2bp is a different function from BLAKE2b, so you can't speed up an implementation of a protocol involving BLAKE2b by dropping in BLAKE2bp, because it will be incompatible.
(More details.)
Security goals.
Poly1305 has very different security goals from ChaCha, BLAKE, Rumba20, etc.
Poly1305 is a universal hash family. The important property for Poly1305 as a building block in a MAC is that, from the perspective of an adversary who doesn't know the secret key $r$ or the values of the Poly1305 function, $\operatorname{Poly1305}_r$ has bounded difference probability: for any distinct messages $x \ne y$ of length up to $L$ bytes and any 128-bit string $\delta$,
\begin{equation*}
\Pr[\operatorname{Poly1305}_r(x) - \operatorname{Poly1305}_r(y) = \delta]
\leq 8\lceil L/16\rceil/2^{106}.
\end{equation*}
Bounded difference probability is cheap and easy to prove. However, an adversary who can see a Poly1305 output can quickly recover the secret key $r$ (or at least narrow it down to $8\lceil L/16\rceil$ possibilities). So to use Poly1305 as a message authentication code, we usually encrypt its output with a one-time pad, $\operatorname{Poly1305}_r(m) + s$, and then to make that practical we derive $s$ pseudorandomly under a secret key from a unique message number.
For example, in Poly1305-AES, we derive $s = \operatorname{AES}_k(m)$ under the secret key $k$. NaCl crypto_secretbox_xsalsa20poly1305 uses XSalsa20 to derive both $r$ and $s$ pseudorandomly under a secret key from a unique message number for each message.
ChaCha is designed to be a pseudorandom function family: if you pick a secret key $k$ uniformly at random, then an adversary confronted with a black box that either (a) computes $\operatorname{ChaCha}_k(x)$ or (b) picks a 512-bit string independently and uniformly at random and returns it (and caches it), given any number of adversary-chosen inputs $x$, can't tell which kind of black box it is. Here, unlike Poly1305, the adversary gets to see the outputs.
Pseudorandomness is generally much more expensive than bounded difference probability, and requires years of hard cryptanalysis to get confidence in it.
BLAKE and Rumba20 are designed to be collision-resistant: the adversary wins if they can simply find two strings $x$ and $y$ such that $\operatorname{Rumba20}(x) = \operatorname{Rumba20}(y)$, and there's no secret key at all.
Collision resistance is generally much more expensive than pseudorandomness and much much more expensive than bounded difference probability, and also requires years of hard cryptanalysis to get confidence in it.
This question is especially interesting considering...
"The security of Poly1305[...] is very close to the underlying [...]
block cipher algorithm." -Wikipedia
‘Security’ here means security as a message authentication code. You and your partner share a secret key $(r, k)$; the authenticator for the $n^{\mathit{th}}$ message $m$ is $a := \operatorname{Poly1305}_r(m) + \operatorname{AES}_k(n)$, and your partner will reject the putative $n^{\mathit{th}}$ message $(m', a')$ unless $a' = \operatorname{Poly1305}_r(m') + \operatorname{AES}_k(n)$. Of course, if $m' = m$ and $a' = a$, your partner will always accept it, but if an adversary who doesn't know $r$ or $k$ tries to find any distinct message $m' \ne m$ with any authenticator $a'$, your partner will reject it with high probability (unless the adversary can break AES).
Again, it is crucial that you and your partner share a secret key. No secret key, no security.
So... why not reconfigure chacha as a Merkle–Damgård like construction. (Or a HAIFA construct, as is done with BLAKE.) Then do a standard H(key || H(key || message)) for effective HMAC? Then, from here, you have CHF, MAC, and AEAD, all from one cipher.
You can build lots of things out of a single primitive—though maybe not ChaCha because it was designed only for PRF security, not for collision resistance. See, for example, Mike Hamburg's STROBE, which is built mostly out of the Keccak permutation (plus Curve25519 for public-key cryptography), or Frank Denis's libhydrogen, which is built mostly out of the Gimli permutation (plus Curve25519 for public-key cryptography).
But it won't beat any speed records.
