I reverse engineered a fair bit of the DS1054Z firmware, including the NAND filesystem code a few years ago. I can't comment on recent firmwares, because I haven't looked at them, but I was left with the impression (on 00.04.04.03.02, I think) that the flash handling was somewhat basic. This code was present in both the bootloader and the application firmware:
https://github.com/rickyzheng/uffs
Community is power, but full reverse engineering of a system of that complexity seems quite difficult.
UFFS is just a generic code that requires adaption/porting for particular project. Simplification or extension could be done in the process. The design uses raw flash part, so in general, the code needs to be updated each time the part type is changed. That alone creates a good source of bugs.
BTW, UFFS is still of v1.3.6, in which "Dynamic wear-leveling, Static wear-leveling is not implemented", according to the pdf document.
For most people (including the managers) new features are more interesting while improved reliability is something difficult to sell. The only incentive to improve reliability is a high return rate. We know how lazy Rigol is with new firmwares. The fact that a new version (I mean 00.04.05.02.03, not the latest one) has appear suggests that the red screen problem was really noticeable. BTW in that version, the boot code is the same as in 00.04.05.02.02, so perhaps a bad block in flash is not the only cause.