They had a variety of pretty big engineering challenges to solve: getting the form factor right, making sure your hand didn't interfere with the screen while using it, getting the pen-and-paper feel right, and getting the e-ink refresh rate down to where you could draw and write on it and have it feel natural.
I'm fine with them choosing to solve those challenges instead of supporting USB mass storage.
...and designing, developing, and supporting your own custom application and its associated protocol isn't an "engineering challenge"?
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".)
Yes, exposing a block device over USBMS is a solved problem.
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.
I'm fine with them choosing to solve those challenges instead of supporting USB mass storage.