Linux – Why is the file system mounted as read-only

There's a bit of an inconsistency or at least, ambiguity, in your story here:

I'd still rather lose it all than facing an 'unable to mount', 'wait for this 10 minutes fsck'

Implies -- although you don't actually say it -- that this is a problem you are actually experiencing. But then:

e2fsprogs-libs (dependency to jfsutils) seems to be hellishly difficult to compile in my distribution.

Meaning you don't have any fsck at all, since e2fsprogs-libs is a dependency for e2fsprogs which provides e2fsck. So perhaps you are still in a planning stage here and have not even tested the system with, e.g., ext4, but instead jumped to the conclusion that you should start with JFS? Is there any particular reason for that?

I've noticed on the raspberry pi exchange (the pi's primary storage is also a SD card) that a significant number of users seem to be very frustrated by problems of this sort, even though the majority (including myself) have never had it at all. At first I assumed these were people ignorant of the fact that the system should be cleanly shut down, but that is not a hard point to grasp when explained, and there are people who report it even though the system HAS been shut down properly.

You've already said you need this to be able to tolerate power cuts (which is fair enough), but I mention this because it implies there are some pis, or some SD cards, or some combination of both, that are just prone to corrupting the filesystem due to some event (surge?) that occurs regularly either when the plug is pulled, or when it is put back in. I also have NOT seen -- and there's been plenty of time for plenty of people to try -- ANY reports of someone saying they've switched to btrfs or jfs or whatever and now the problem is solved.

The other mysterious thing about this is even if people are yanking the cord, this should not regularly result in an unusable filesystem. Certainly I've done it a bunch of times w/ the pi, and scores if not hundreds of times w/ a regular linux box (the power was cut, the system has become unresponsive, I'm exhausted and angry, etc.) and while I've seen minor data loss, I've never seen a filesystem corrupted to the point of being unusable after a quick fsck.

Again, presuming all these reports are true (I don't see why numbers of people would lie about it), there's something much more going on than just not cleanly unmounting, but it seems to only affect a small percentage of users, implying again some kind of common hardware defect.

On the pi I write -y to /forcefsck in a boot script, so that on the next boot it is run automatically and any problems are fixed, regardless of whether this appears to be necessary or not. On a 700 Mhz single core this takes ~10 seconds for a 12 GB filesystem containing ~4 GB of data. So "10 minutes" sounds like an incredibly long time, especially since you've already said "This is the small filesystem for write!".

You might also consider calling sync at regular intervals.

Finally, you should update the question with more factual, specific details of the problems you have actually encountered, and less hyperbole. Otherwise it just looks too much like a premature XY problem, which will likely get quickly skipped over by people with a lot of experience and potential advice for you.

Then why do we even need a directory cache?

It's just another level of caching. Even if all the path components can be found in other caches, it still takes time to traverse them all. So the directory cache provides a way to cache whole paths and avoid looking things up path element by path element from the root each time.