That's not how it works.

The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.

You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.

And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.

If the FSF thinks that even having proprietary blobs is bad, why does the rule apply only to mutable copies? Why not just refuse to certify devices with hardware that contains blobs contrary to their values? There's no practical argument as to why it's only acceptable to allow a nonfree blob if it's not burned into silicon. Even if it did matter, from the perspective of a normal person, microcode in a chip versus microcode loaded after boot offers no meaningful distinction in functionality or freedoms. If the point is high standards, then why have this loophole at all?

If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.