[Galaxy Note GT-N7000 General] jetmarc:
Writing as an embedded engineer but not working with this EMMC chip in particular, I think of the following:

The firmware within the EMMC must be complex. It can easily reach a code size of 32kb and beyond.

There exists a kernel patch set in android that fixes an issue in some Samsung EMMC firmware. It clearly sais that it patches the "internal sram". The patch payload looks like thumb code (rather than data). This suggests that the firmware executes from RAM, not ROM.

If the firmware executes from RAM, it must be loaded during powerup. Where can it come from? The obvious solution is load it from some reserved area of the NAND array.

Typical NAND bootstrap (on systems with no alternative boot method), works with either a tiny ROM to init the CPU, load the first page(s) and then run them. Sometimes it works by just mapping the NAND to the reset location and using memory with a "guaranteed good first block". Either way, such a system is completely hosed when the array is invalid.

Apparently this EMMC has the IO command protocol implemented in the firmware, and there is no alternative boot method available. Otherwise the statement about dangerous updates makes no sense. When the firmware is gone, so is the only available communication channel (the command protocol).

This leads to the question of how Samsung programs the firmware initially, when the chip still has no communication channel? NAND arrays always need individual programming anyway, because defective blocks are marked during the manufacturing process. The firmware is most likely programmed at this point, too. If the chip is still not packaged (or maybe not even sawn), programming can be done through an interface that becomes unavailable later (extra IO pads that won't be bonded to external pins, for example).

With all these facts and assumptions in mind, the danger of the "official" fix is probably something like this: Read each and every raw block through a hidden command. Powercycle as often as necessary to accomplish this. Reconstruct the intial bad blocks and the new bad block list from that. Extract the unique identifiers that need to be preserved (IMEI etc). Also try to extract (or guess) the erase counter for each block. Assert that enough information is available to continue. Issue another hidden command to completely wipe the array (including firmware). Use the hidden memory patch command to upload the new firmware, and yet another hidden command to flash it into the array. Then do the same with the badblock map and erase counters. Reset the chip and use regular commands to partition and restore the unique identifiers and the Android bootloader. Now you have a blank phone that can be flashed using the usual tools.

If the process is interrupted in the critical stage (from "erase whole array", until "finish flashing the new firmware into the array") then the EMMC will be dead forever. There's also a slight chance that the block that holds the firmware was marginal and develops a new defect during just this erase/write cycle (NAND can do that!). No precautions from our side can completely eliminate this risk.

Of course there exist another possible fixes, with less risk. For example, one could upload a special firmware image, with tools to repair the damage without wiping the whole array. Future damage is avoided by proper kernels anyway and we can continue living with the old firmware. This fix would pose no risk for the user, and no additional risk to Samsung either (they would have to reveal many hidden commands and also complete firmware images in both scenarios). However, it would need extra engineering to develop, while the other fix mostly uses code that already exists.