I believe that gfw.exe is facing the same issue in re-compiling the BIN files as the other programs due to the firmware's strong encryption.

I also believe proper decryption is possible if you can find an expert with the skills who's prepared to risk the wrath of Garmin for breaching their EULAs if they get found out. Someone may already have solved this but not been prepared to release the secret due to the way G has aggressively pursued others in the past decade for similar infringements.

In the exception message you quoted GFW has reported on the firmware's binary component meant for the "fw_all" region (rgn14; hex 0x0E) which is the main system software. My interpretation is that it's reported 14 as having an invalid format only because it doesn't know how to deal with the encrypted data. By comparison, RGN_Tool.exe does make an RGN from the GCD while only grumbling about the First Section. The result is an invalid RGN file which can't be properly flashed anyway. I didn't test mbirth's tool myself, but your results speak for themselves regardless.

The thing is this: In most conventional Garmin firmwares, i.e. the non-encrypted ones also using a ramloader ("boot.bin") component, the binary components are identical in GCD and RGN files, so theoretically a GCD can easily be converted to an RGN and vice versa by changing/adding some known data. That's essentially what RGN_Tool does 'on-the-fly' when you convert a conventional GCD to an RGN but because RGN_Tool cannot do that with the encrypted fw it's most unlikely that it can successfully be done manually using a hex editor either, at least without it first being decrypted. It would then need to be properly re-encrypted following manipulation as well.