I totally agree that Flash is not Disk, and the industry is wasting its potential by treating it as a fake disk. This recalls a previous era when disk replaced tape in bulk storage but many algorithms continued to use disk as if it was tape, a process which played out for a decade.
However, Flash is also not DRAM. Its latency is too long, both on reading and writing. It needs sequential writing, and writing takes much longer than reading. It needs a block structure much bigger than DRAM words for effective error correction. There must be advance planning for erasure, which takes even longer than writing. And finally there must be active wear management and scrubbing to get the best life out of the devices.
Flash is a write-sequential, read-random storage device compatible with log structured storage systems. A lot is known about log structured storage, it used to be fashionable in database theory in the late 80s and early 90s, ironically it was generally abandonded since HDDs could not scale the random reads which it needed, just as Flash was enterring its first commercial uses (in devices so small and obscure these worlds never overlapped). But reading some of that literature now you can see that Flash is the ideal physical medium. It provides strong support for high performance and transactions, while being a great fit to the usage pattern which is best for Flash.
Using Flash to emulate Disk has been a mindless way for it to get to market but as you say, very poor exploration of the true potential. However, pretending it is DRAM is just to make another mistake. Why does Flash need to be like something else? It is its own thing, and the best way to use it is to properly understand it, and design for what it is not get stuck in the past catalog of devices. It is high time computing courses properly explained it too, since HDD is rapidly becoming a niche for cold data rather than actively used data.
Thanks for a very well-formed comment. You and I see things the same way.
Although I don't think that you can mindlessly add NAND to a system to replace DRAM, I think that it can be managed similarly from the perspective of coherency (which is a big reason that a lot of people shy away from using DAS-type solutions, and was a stumbling block for Fusion-io early on.)
Cache is managed differently than DRAM, and DRAM should be managed differently than NAND, but all three should be treated as memory. In the case of NAND this management must involve measures to reduce write traffic and manage slow erases and writes, serial access, etc. There is no reason that these can't be a part of the file management of the operating system.