That said hash function can be used to reverse the original image as much as it can. Not all features are preserved but critical ones likely will.
It’s just that the underlying algorithm has adversary attack in mind and has some countermeasures built in to reduce the risk. In Apple’s application here, there’s two layers of encryption, one encrypts each slice of the original image, and the other one packages the whole processed image hash. There is no need for more layers since only two parties are involved. But if multiple parties are involved, there could be more slices and more layers.
Think of this way: you are sending an image (presumably CSAM image) to Apple iCloud server. The image is first sliced into smaller pieces of manageable size, compute with a function to get a grid of numbers that closely relate to the original image. This grid of number got hashed the same way original image is being reduced, until there’s one final number that represents the original image but a number alone doesn’t mean much.
Apple wants to see the content of the image, they’d need to know sufficient number of slices of the original image to recreate what it once was. Since the algorithm is reversible, Apple can then use the number to reverse back the chain and recreate an image that is as close to the original as possible. However, if only some slices are reversed (because others are encrypted), Apple would not be able to process available information to figure out what the original image is.
Or, think of this another way. A letter being torn apart into small pieces can still be recreated if sufficient number of pieces are found and contents are distinguishable.
I believe what Apple is trying to achieve here is unless they receive enough pieces of image that closely resembles existing CSAM image, what they receive is effectively as if they receive nothing.