I agree that in-memory workloads are important, and that is why we compress on flush rather than compressing on write for our compression plugin, and it is why we should spend some time optimizing reiser4 to make its code paths more lightweight for the in-memory case. At the same time, I think that the workloads where the filesystem matters the most are the ones that access the disk. With computers, in a large percentage of the time that people notice themselves waiting, it is the disk drive they are waiting on.
So while I sympathise with you wanting reiser4 to be tuned for "big"
storage, please remember that a good proportion of the installs are
likely to be running "in-memory" workloads.