I'm fine with them choosing to solve those challenges instead of supporting USB mass storage.
USB mass storage requires exposing a block device with a filesystem, which is error-prone and complex.
The point is, USBMS is a solved problem. My MP3/MP4 players, my Android phone, my satnav, even my soldering iron[1] can do it. The Linux kernel, which reMarkable uses, already includes support for this[2]. It's conceptually very simple --- in its most basic form, if the device detects that it's plugged in, it unmounts its internal block device and lets the host control it, and vice-versa. More advanced functionality, such as found on Android and many MP3/MP4s, lets you choose whether the device or the host controls its storage, via a very obvious interface on the device itself (one position is "charge only", the other is "transfer files".)
[1]https://hackaday.com/2017/07/24/review-ts100-soldering-iron/
[2]https://www.kernel.org/doc/Documentation/usb/mass-storage.tx...
Exposing files from a device's internal storage (which is ext4 in this case) over USBMS is very much not a solved issue. You'd have to copy the files back and forth or write a driver which emulates a FAT filesystem.
The alternative would be to use FAT internally and expose that block device, risking corruption (you have no control over what is done to your poor filesystem).
None of my Android phones can do that. In fact, Android used to expose the raw device in earlier releases and stopped doing it because it was too unreliable and the UX was bad since the filesystem had to be unmounted.
However, here's what Martin (the CTO) has been playing with:
Personally I would be ok with my device disabling it's UI while it emulated a mass storage device when plugged into a host.