Well you cant call it caching. By definition, that means data is written to both drives at the same time. In the case of Fusion Drive data is always read from and written to the SSD. It is basically a software which moves files around.
Writing data to both the cache and the main store is not a fundamental property of caches. Consider, for example, the caches on the microprocessor of an x86 chip. The only time both the cache and main memory will contain the same data is if the trait is set to 'WT', which is very rare.
It's true that (coherent) caches behave in such a way that you can't tell that the data isn't duplicated at each level, but that's achieved by writing back the data when, for example, an external device requests some particular cached data.
If the cache is persistent, and external devices can access the cache as easily as the main store, there's no particular reason to write data back, other than evictions [1], i.e., you should expect the cache to basically be "a software which moves files around"
[1] This isn't strictly true -- depending on the access patterns and the characteristics of the cache and the bus, you might want to opportunistically write data back to avoid having to write back on an eviction. Disclaimer: I've only worked on microprocessor caches and not disk caches, so I'm not intimately familiar with performance traces for disk caches. However, based on simple back-of-the envelope reasoning, it seems to make sense to make disk caches the type of cache you consider not to be a cache at all.
Also, is it really true that data is always read from the SSD? So if a block is requested that only exists on the hard drive, the data must be copied from the hard drive to the SSD, then read from the SSD--rather than simply reading the data from the hard drive?