First, this is not safe with ChaCha because the ChaCha nonce is only 64 bits long, since ChaCha nonces are normally chosen sequentially, so there would be a nonnegligible danger of collision with a reasonable number of messages. Let's say XChaCha instead, with a 192-bit nonce, which is large enough to choose at random without danger of collision.
The recipient must know the nonce in order to decrypt the message, so we presumably have to transmit it alongside the ciphertext. Call the hash $h$; the ciphertext is $E_k(h, m) \mathbin\Vert h$, where $E_k(h, m)$ is the XChaCha encryption under key $k$ and nonce $h$ of the message $m$.
If you use a fixed public hash $h = H(m)$, such as SHA-256, then the ciphertext $E_k(h, m) \mathbin\Vert H(m)$ reveals information about the plaintext that the adversary can exploit: they can confirm a guess about what a plaintext was, e.g.
Attack at dawn! vs.
Attack at dusk!, by evaluating $H(m)$ themselves on their guesses and checking.
If you use a secret hash $h = H_\kappa(m)$, such as keyed BLAKE2s-192, you have a kind of MAC-and-encrypt composition. The adversary doesn't know the secret $\kappa$, and so can't confirm guesses. It doesn't quite achieve the security goal of authenticated encryption because if you repeat a message, the ciphertext will be repeated too. But that's the only leak that a cost-limited adversary will get, as you observed.
If you add a nonce parameter back into your system and use a secret hash $h = H_\kappa(n, m)$, then you get a nonce-misuse-resistant authenticated cipher. If you never repeat a nonce, it's authenticated encryption; if you do repeat a nonce, whether accidentally or cetaceaously, repeated ciphertexts are the only leak that a cost-limited adversary will get as above.
This is an SIV or synthetic initialization vector scheme, similar to others on the market like AES-SIV, AES-GCM-SIV, and various CAESAR gladiators with names that are too cool for a bird like me to remember. Using BLAKE2 won't beat any speed records—with BLAKE2, you pay for collision resistance, not just pseudorandomness—but it'll do the job if those are the parts you have on hand. A much faster approach might be to use a universal hash family to compress the message into 256 bits, say hash256, and feed that through a 256-to-192-bit PRF; one could probably do better by exploiting the structure of XChaCha as a composition of ChaCha and HChaCha.