For what it's worth the squabbling doesn't make any noticeable difference. The Amigans have never stopped squabbling and they have a few thousand users. The Be-lievers work hard to show a united face in public, and their numbers are hard to estimate, but perhaps not much more than the Amigans... People who get into retro-computing tend to either be all about nostalgia, and thus their platform choice is associated with happy memories from their youth, or else they're like Indie Rock Pete and actively choose a platform because it's unpopular. A bit of chair-throwing makes no difference.
The wear-levelling algorithms in ordinary consumer flash devices are nothing to do with FAT. Cheap consumer flash has a built-in wear-levelling algorithm, and it is normally formatted with FAT, but the two aren't related.
FAT is a ghastly filesystem used with DOS, nobody likes it but it became the de facto solution for devices which must be shared between a variety of machines simply because of the popularity of PCs running DOS.
The wear-levelling algorithms (except in high-end SSD devices) do something noddy like maintain some blocks in a ring buffer and rewrite the next available block in the ring on update. This avoids writing the same block over-and-over, and thereby extends the life of the device.
JFFS2 (and its predecessor JFFS and their successor LogFS) are intended for use with a software translation layer on raw flash devices ("memory technology devices") with no built-in wear levelling. So for example, a set top box with 2MB of RAM and 32MB of raw flash, might use JFFS2 to store some resources like graphics for its OSD. When you switch the box on, JFFS2 requires a full filesystem scan, but that's OK because 32MB doesn't take long and people leave their STBs in standby anyway.
FAT and JFFS2 are like car batteries and jet fuel, they may share some properties in theory, but they have no real applications in common.
“I know what to do; reduce block of memory assignment where the printer needs only horizontal slices, to, er, horizontal slices.”
Your naive analysis applied to the RISC OS port's examples results in the conclusion that Gutenprint uses less than one bit per output dot. Does that really sound right to you? Doesn't it seem more likely that they already use a divide and conquer solution and your "suggestion" is redundant ?
Of course its possible to write a driver which runs in a lot less RAM, but it will have worse quality or run much slower and probably both.
“The PC manages it quickly, therefore it must be possible to emulate it quickly”
This doesn't follow. First of all, the hardware is quite different. So for example if the PC can manage fifty times more floating point operations per second then you're going to do most of the heavy weight maths 50x slower than the PC. Or take the CPU cache. The Iyonix for example has only 32kB of cache. So if you've got an algorithm that does random access to 40kB of data (a quite modest size for a LUT in image software), you're thrashing the bus and suddenly the whole CPU is waiting for RAM. On a typical PC that same routine would run from cache, perhaps 10 times faster than the Iyonix even if they were the same CPU speed (and of course the PC will be faster).
But it gets worse - the PC will most likely be running a somewhat modern OS. Even OS X with its laughably naive I/O layer and VM will massively outperform RISC OS. On Linux there are already people trying to optimise for SSDs where there's zero seek delay, finding inefficiencies so small that they were unmeasurable just a few years ago.
“whatever happened to Postscript, TWAIN, etc?”
Postscript is still used at the higher end. It is a full-blown programming language. To run it the printer needs a lot of RAM and a fairly high-end CPU, proportional to the required output resolution (otherwise it will be annoyingly slow). Doing the work in the PC instead thus represents a considerable saving. On a $1500 laser print offering a full Postscript interpreter, including the Adobe license and fonts, is a reasonable decision. On a $100 inkjet printer it isn't going to happen.
TWAIN is the API used to make scanner drivers "drop in" to other applications in Windows and sometimes Mac OS. In the very recent versions of the API there's more thought for other platforms (mainly Linux) but it isn't (as popular idea seems to have it) a platform independent HCI like UVC or EHCI. Each individual "TWAIN compliant" scanner ships with its own OS-specific drivers.