I ran it diskless for years with read-only NFS mounts. Set up syslog and a pflog daemon to send logs elsewhere, and you don't need write access most of the time.

I believe that while the file system does not have journaling, that can be offset by applications. I.e. I think the SQLite Write Ahead Log would still protect you against data loss even if there's no journal in the file system, assuming you set various settings correctly. So I think it kinda depends on how the applications store data.

Yeah, if OpenBSD had ZFS it’d be perfect.

What's the use for a writable filesystem in network gear, that is detrimental if lost at power outage? Some sort of very important logging?

Out of curiosity, why put "router" in quotes?

OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. If you lose power it will lose the specific data currently being written to disk. It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data that has yet to land on disk if the power is cut.

I've had my share of sudden power cuts hit OpenBSD during the 20+ years I've been using it, and I have yet to ever see its file system actually go corrupt.

A sincere question: what important data does your router frequently and busily need to persist? If you don't have a UPS for it, perhaps it isn't too important after all. Maybe we have different perspectives of what a router is and should be. I manage a router (with OpenBSD) and it can drop off the power grid at any moment without losing anything of importance. If your router is in fact a multi-functional server I can understand the notion. Consider making all of the file systems fully synchronous. It has worked great for me for two decades.