People are expecting to embed WASM[1]. A generic FAT can provide a lightweight storage abstraction for such work. The WAMR AOT compiled runtime is 50K; 2.5-10% of the flash memory on a STM32F4, for example. Obviously not appropriate for the smallest extant MCUs. Otherwise it's a viable choice.
When I found FatFs, I realized I had a perfect fit: a realish filesystem with an API that I could map right onto system calls, and FAT32 - a klunky old jalopy that will need defragmenters and other disk tools to maintain it. It'll make for an altogether more interesting ecosystem and a gentle challenge for the user to maintain.
Also, there are many areas of my javascript that are primed for conversion to C -> WASM, like sprite collision detection. JavaScript optimizers have done ok with my code, but I'd like my compy to run fast on mobile too. If I am successful with FatFs, I will have a convenient spot in my codebase for converting my busy number-intensive routines into WASM.
What's the value of having direct device access in Javascript? Are we expected to give the browser raw block device access now? Maybe we could implement a FAT layer on top of S3, but I really don't see the value in reimplementing block-level storage on top of object storage.