Hard drive cache size does not matter anywhere since all modern operating systems do their own caching, and have MUCH more memory to use for it. If it's been recently accessed, then it's going to be in the OS cache anyhow so having it in the drive cache doesn't matter since the OS won't ask the drive for that data again.
To compare to CPU caches, it's like having your nice fat 8MB L3 cache modern cpus have, then watching the years go by and finding CPUs with a 128 MB L2 cache that is 32 times faster, but still having that old, slow 8 MB L3 cache. It won't be doing any good since the L2 is always consulted first and is both larger and faster. At that point, arguing about whether the L3 cache should be 8 or 16 MB is a moot point since anything in the L3 will also be in the L2 so the L3 won't even see the request.
To see the drive and kernel caches in action, you can play around with dd to see how fast you can read from the drive.
sudo dd if=/dev/sda of=/dev/null bs=52488 count=1
This will read 512kb from the drive. Repeat it a few times and you will start to see some very fast numbers. On this old machine I have handy, I'm seeing on the order of 751 MB/s. That is with the kernel cache. Now if you throw in the iflag=direct option, that will disable the kernel cache, allowing you to measure the speed of the drive's cache. Repeating this I see only around 100 MB/s, which is about the max transfer rate of this old IDE interface. That isn't much better than the drive's unbuffered throughput of around 61 MB/s.
Now ask yourself what good that slower, smaller drive cache is doing when you aren't bypassing the kernel cache.