Excellent article. Thanks for the research and writing it up.
Reading the article, it seems to me that we're going through another "abstracted by an IO controller" shift similar to what happened when SCSI and then IDE drives were introduced. Before that -- back in the late 80s/early 90s hard drives ("MFM" and then the later "RLL" with 33% more storage!) -- were interfaced with motor control signals and analogue read/write head signals through to a controller card in the computer which managed the drive at a pretty low level (mostly took care of the digital to analogue signals, and a little bit of the timing requirements); the disk driver was required to do the rest in software, including things like remapping bad blocks. As drives with SCSI (and later IDE) controllers on board were introduced, this detail was abstracted away -- it became "read block", "write block", etc, with quite a bit of abstraction as to how that was done. And this abstraction has only increased over time, to the point where (as the article notes), things like heads/cylinders/sectors are completely hidden and irrelevant. (And unlike the MFM/RLL days, there very much aren't the same number of sectors per track; old drives were used with constant angular velocity, and modern drives are used with constant linear velocity.) So basically as things got more complicated, it was offloaded to a separate computer -- built onto the (SCSI/IDE) drive -- and it took a while to get those to the point of being optimally efficient. It also took a _long_ time for OS developers to get over the idea that they could optimise for track layout, etc, the way they used to have to do so when "closer" to the media.
With the shift from raw-NAND-storage to SSD/MMC/CF/IDE-attached/SCSI-attached flash, we seem to be at a similar point to where we were with magnetic storage in the early 1990s: everything is clearly moving in the direction of offloading the IO work to a separate controller (the flash controller), but the implementations in those separate controllers are either fairly inefficient and naive, or end up optimising for a particular benchmark ("FAT32 file system", "video recording/playback"). Hopefully given a few more years, and increasing uses in situations where FAT32 isn't the answer (eg, lots of non-Win-XX based embedded devices) the flash controller firmware will improve to be more generally optimised for scenarios other than FAT32/video. (And presumably over the same time micro controller costs will come down a bit so that, eg, not everything has to be fitted into 2000 entries in RAM in a tiny micro controller.)
Until then, knowing what the algorithms are inside these devices really does help in making more optimal choices of device for the workload, and in designing file systems to use on them. (Finally there seems to be a media type that really cries out for a log based file system at either the flash controller level or the OS level -- or both. On magnetic media the seeks required used to be a major problem, and flash eliminates that issue.)