Okay, several things here.
First of all, RouterOS either uses YAFFS or UBIFS, depending on board model. One of the posters in the RB750Gr3 thread mistakenly said JFFS when he meant YAFFS, and if marakasmalan had been reading that thread, that might explain why he mistakenly typed JFFS2 originally, as well. JFFS is not used in any version of RouterOS, past or present.
Second, it is actually not settled whether RouterOS version of YAFFS has custom modifications or is simply "older". I suspect it has actually been modified by MikroTik, though I admit have not taken the time to study this in detail. I just know that even back when I was playing around with Kamikaze, Backfire, Attitude Adjustment, etc. on YAFFS RouterBoards, and even if the OpenWRT kernel I was using had the exact same partition layout burned into it as RouterOS (partition offsets were all correct), trying to mount one of the RouterOS MTD partitions using the OpenWRT kernel's YAFFS implementation would end up causing filesystem corruption. Apparently @sidepipe from the other thread had similar experiences. I have not tried to repeat this experiment in some time. These days I just make sure that if I actually care about preserving the contents of the partitions, I build and use a kernel based on MikroTik's official Linux patch sets which contains their (allegedly) forked implementation of YAFFS, instead of an official OpenWRT kernel.
Finally, I am sure that the author of the bits quoted from the wiki page at https://openwrt.org/toh/mikrotik/common had good intentions, but there is no need to back up either the RouterOS software license key, or even RouterOS itself, from a RouterBoard before flashing it with OpenWRT. Doing that is a complete waste of time.
A quick primer on RouterOS licensing:
License enforcement is made up of two parts: Software-ID, which is an 8-character string that uniquely identifies a RouterOS installation, and the license key file which describes the RouterOS feature set that you are allowed to use on a given installation. The license key file is generated based on a particular Software-ID, so that you may only load the license file onto the particular router that you bought the key for (otherwise you could buy a single key and load it onto as many routers as you wished).
This system was engineered by MikroTik back when they only sold software, and did not manufacture any hardware. RouterOS started out as x86-only, and you would buy a software license to install it on any standard PC hardware. For x86 RouterOS -- which still exists! -- the Software-ID was generated based on a hash of several unique properties of the disk that the OS was installed on...only MikroTik knows the exact "recipe" of the hash, but it is believed to take into account the disk make, disk model, and disk serial, as well as possibly the contents of the MBR partition table and/or the particular ext2/ext3 filesystem that RouterOS lives in. The good thing about this system is that it means your RouterOS license is tied only to the disk itself, and not to the entire PC (for example, Microsoft / Windows Product Activation), so you could take a disk with RouterOS out of one PC and put it in another (to upgrade your "router" hardware) and not have to buy a new license. Since it is tied to the disk, you cannot "clone" the license by making a bit-for-bit copy to a second disk...when you boot the "cloned" RouterOS on the second disk, you will find the Software-ID has been re-computed and so your license key will no longer work. Unfortunately, since it also seems to be tied somehow to either the MBR or the main filesystem, if you reformat and reinstall RouterOS onto the same disk, the Software-ID will also change then, too, and your license key will be forefeit. Also, if your disk dies, your license is also forefeit.
When MikroTik started making their own hardware, and that hardware wasn't x86-based and had built-in, non-user-replaceable storage (soldered-on flash chips), they continued to use the same licensing model but came up with a different way for non-x86 RouterOS to generate Software-ID. Software-ID on a RouterBoard is NOT based on the disk/storage. It is based on something else about the RouterBoard that never changes...we don't know what exactly (maybe board serial number, or MAC address of eth1? who knows), but we do know that a given RouterBoard will never have its Software-ID change. The Software-ID that it ships with from the factory is the same one that it will have for life, no matter how many times you wipe the flash chip that holds RouterOS on it and re-install the OS.
Not only that, but both the Software-ID and even the license key itself appear not to be stored anywhere on the main flash chip where RouterOS lives, but rather somewhere on the bootloader's SPI flash chip, which is a separate chip, and it is not touched at all by the OpenWRT flashing/installation process (unless you decide to replace MikroTik's RouterBOOT bootloader with something else like U-Boot...so don't do that!)
I have written zeros to the entire main OS flash chip on a RouterBoard many, many, many times, both via RouterBOOT as well as via "flash_eraseall" from within OpenWRT, and then re-installed RouterOS on it later, and the license key that the board originally came with was always preserved and always automatically detected by the RouterOS installer ("NetInstall"). I have never, ever had to back it up...it is always just "there".
So not only is there no reason to back up RouterOS on a RouterBoard in order to preserve the license key (since the license key isn't even stored on the filesystem with RouterOS for non-x86 versions of it), but there is also no reason to back up RouterOS simply so that you can return to it later...you can always reinstall RouterOS onto a RouterBoard that you have flashed with OpenWRT using MikroTik's "NetInstall" utility, and if you are worried about backing up RouterOS so that you can preserve the version that your board shipped with, you also don't need to worry about that since you can install any past version of RouterOS with NetInstall...you aren't forced to go to the most recent release if you don't want to. There's no downgrade prevention or any of that nonsense.
In fact, as long as you don't touch the SPI flash where RouterBOOT lives, RouterBoards are virtually unbrickable[1], which is one of the reasons why I like them so much...
Hope this helps,
-- Nathan
[1] ...the main exception is if eth1 is physically damaged, because that is the only interface that RouterBOOT can netboot from. So if eth1 is dead and you screw up the contents of the OS flash, then you're in trouble...