Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool
Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless.
The mainline kernel with simplefb just uses the framebuffer passed over from the bootloader, but can't change its configuration. For the kernel is is just a memory buffer where one can write pixel data. The framebuffer setup is done in the U-boot bootloader. I believe that the framebuffer is initialized by U-Boot only when something is detected to be connected to HDMI and queried via EDID, but may be wrong.
I had a CB2 board myself (but not anymore) and at least my board was passing the lima-memtester test with DRAM clocked at 480MHz. My board board was an early one and had GT memory chips (GT8UB256M16BP-BG). But SK Hynix chips (H5TQ4G63AFR-PBC) have also been observed in the wild later, according to the pictures from the https://linux-sunxi.org/Cubieboard2page. Sometimes the choice of DRAM chips affects reliability. I observed different DRAM reliability behaviour with NANYA and HYNIX chips on LinkSprite pcDuino2 boards. And Olimex also reported reliability problems after changing the DRAM vendor on some of their boards.
Could you please check the DRAM chip markings on your board? Also it would be great if you could test the board at different DRAM clock speed steps (432, 456 and 480) in lima-memtester and find the exact crossover point where things become unreliable. There is no need to run lima-memtester for 30 hours except for the final verification, usually something between 20 minutes and 1 hour is enough. Comparing lima-memtester results with your old method is also interesting (do they have similar sensitivity to detecting errors? is one of them faster at detecting problems?).
Naturally, it's a bad news that your Cubieboard2 fails with the mainline U-Boot default settings. We clearly need to fix this but need to do a bit of an investigation to see what is going on, whether the DRAM chip vendor makes a difference, and what is the maximum reliable clock frequency on different boards. For example, a perfect example of such investigation is https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit