Does AEAD provide any benefit over raw cipher in this setting?

I'm working on a cryptographic data store where blobs need to be identified and referenced via a hash of the encryped data. Think Merkle tree with encrypted nodes. In such a setting where the hash already establishes authenticity (assuming the hash function itself is not broken), is there any value in using an AEAD rather than just using the cipher directly?

I believe this is different from the classic encrypt-then-MAC topic because there is no hash or MAC stored with the blob to authenticate it. Rather, the hash is an external reference from elsewhere that is already authenticated (not subject to aleration by an attacker).

A further detail I originally omitted thinking it was irrelevant, but in hindsight it seems to clarify the problem: there is no preshared symmetric key; the key that could be used in a raw cipher or AEAD is one derived from an ephemeral secret and the receiving party's public key via ECDH. As such, any attacker who knows the public key can produce a blob with a valid AEAD tag using their own ephemeral secret. However, assuming the hash function is not broken, such a blob will not hash to a value the receiving party expects, and thus will never be used.

If there are already means to authenticate the plaintext then it is indeed possible to skip authentication of plaintext or ciphertext by other means.

There are of course some catcha's.

First of all, the plaintext should not be used by any means before the authenticated hash value is verified. If this isn't the case then the attacker can change the plaintext, which means that the party is subject to many types of attacks including plaintext oracle or possibly fault injection.

Furthermore, the implementation should not provide any information on the decryption process. If it does, then the implementation may become subject to side channel attacks. Worse, if e.g. CBC is used then padding oracles apply. So is makes more sense to use AES-CTR or a stream cipher such as ChaCha20.

The last two design/implementation mistakes can be avoided when using an authenticated mode. So there can be some use to authenticated mode even if the key cannot be trusted. One disadvantage is that other developers could assume that authenticated mode does provide the authentication required, and start using the plaintext even if the messages haven't been authenticated yet.

Personally I would not use authenticated mode for this.

Note that the IV handling is not specified in the protocol that you describe. It is not needed to be part of the hash if that's protecting the plaintext rather than the ciphertext. However, you should make sure that it is unique for each message that is encrypted with the same key (and if you use the CBC mode, unpredictable).

I'm also not seeing if the protocol is susceptible to replay attacks and plaintext guessing attacks, if the authenticated hash is used both for identification and authentication.

A hash establishes integrity, not authenticity. An AEAD tag or MAC of the ciphertext establishes both integrity and authenticity.

If the hash is of the ciphertext, the attacker can simply modify the ciphertext and compute a new hash, since hashes don't depend on a secret key.

If the hash is of the plaintext, you get the same weaknesses as with "MAC-then-encrypt" schemes where you violate the cryptographic doom principle.