It's all about latency...
Enterprise arrays have had large amounts of NV cache for a long time, usually in the form of battery-backed dynamic memory. In some arrays this can amount to hundreds of GB. The main purpose of this is to reduce the impact of latency of physical disk I/O and to optimise that I/O activity at the physical device (by, for instance, such things as roll-up writes, full-width stripe writes on parity RAID, read-ahead on detected sequential I/O etc.). A secondary, but important function, is also to cache the logical configuration of the array (so virtual device definitions, sparse snapshot mappings and so on). That way the I/O latency for writes (which can generally all be cached unless cache is saturated due to back-end IOP congestion) and cached reads on a SAN can be reduced to about 0.5ms from perhaps 6-10ms (on a heavily used array). However, all caching mechanisms, whether NV dynamic ram or flash based get into areas of diminishing returns as each extra GB buys you less and less improvement. If you happen to be running the sort of random transactional OLTP app where the read hit rate on cache is relatively low, it is very likely your transactional time will be I/O bound by read latency. As modern databases tend to keep good read cache candidates in server memory, the array tends only to see the random elements. Thus it's not unusual to see DBs having logical rates of read I/O many tens of times higher than the physical reads. Thus the array tends to get all the difficult, uncachable reads. This latter is very commonly the limiting factor on transactional throughput on transactional systems. Ultimately hybrid approaches will always limit throughput unless the amount of cache approaches the total DB size.
There is also another issue - that is start-up time with "cold" cache in the database. Typically when such an app starts, the database floods the array with vastly more read requests than when the DB is running in a stable condition when its internal cache is populated. This tends to be far more random IOPs than the storage array can possibly cope with and thus I/O latency becomes very high. This, in turn, causes backlogs, poor caching behaviour and instability. Indeed very many large applications have to be started slowly to avoid this - it's not uncommon for large applications to require a ramp-up over an hour or two before reaching full throughput.
Cached (including hybrid array) approaches are of only limited benefit for these situations. For very large transactional systems with lots of random access, only a fully solid-state storage mechanism will meet requirements. Hybrid approaches are going to be of limited value in this area.