Both the Arduino bootloader and the user-firmware are stored in the same flash memory, inside the ATmega328. Whenever ATmega328 is powered up or reset, the bootloader runs first, and waits briefly to see whether the Arduino IDE (or avrdude utility) is trying to send new firmware. If not, then the bootloader runs the user-firmware that is already in the flash memory. The exception is when the ATmega328 is held in hardware-reset while an external device programmer (ICD) writes directly to the on-chip flash. This is how the bootloader must be installed on a brand-new, blank ATmega328. (This is generally applicable to most modern microcontrollers, not just Arduino/ATmega328; pretty much any microcontroller that has on-chip flash with some kind of bootloader.)
The board accepted a new firmware after the rewrite of the bootloader
This confirms that the ATmega328's internal flash memory somehow got erased or modified: the bootloader was not able to start and run the user firmware, yet the chip did not seem to show any signs of being permanently damaged. Surprising but not impossible. It's hard to know exactly how that happened in this case, or whether there is any permanent damage to the ATmega328.
It's possible that a firmware design error (bug) could have caused an unwanted write to the flash memory. This seems not very likely, but possible if the firmware was supposed to store into EEPROM and instead stored into FLASH ("PROGRAM" in Arduino terminology).
It's possible that the chip's under-voltage lockout feature was not configured or enabled, and somehow the power supply voltage momentarily dipped down too low for correct operation. That doesn't mean that the chip suddenly halts: it can keep trying to fetch-decode-execute instructions, even though at low voltage, not all parts of the chip may be working correctly. There's no way for the lowest-level logic to know whether a 0 should have been a 1. The under-voltage lockout or brownout feature is supposed to halt or reset the ATmega328 if the power supply voltage is too low. However this feature is a little bit complicated for the beginner Arduino crowd, you have to know what clock frequency and supply voltage your system needs. Arduino is supposed to be a 5V powered system so it can run at the full 16MHz speed, but the ATmega328 itself can run at lower voltages if the clock speed is slower (3.3V-8MHz is one that I commonly use). If running from a coin cell for as long as possible, a slower clock and a lower under-voltage lockout is appropriate. But if you're using the Arduino UNO suite as-is, the under-voltage lockout should already be preventing operation at low voltages below 4.5V.
It's possible that the power supply voltage was momentarily too high; if it exceeds the Absolute Maximum Ratings (see ATmega328 datasheet) then permanent damage can occur. It's not always obvious that the chip has been damaged. Usually in a pro setting the first clue is that the supply current increases. If you're not using a bench power supply, but just powering through USB, then it's hard to notice a small increase in supply current, or a slight rise in the chip's temperature. If the ESD damage shifted the analog reference voltage by 5%, that would affect "AnalogIn" measurement accuracy but nothing else. If the ESD damage destroyed only a couple of PN junctions within the ALU, maybe it would cause math errors under some conditions. (The ancient intel Pentium CPU once had chips in the wild that used a lookup table to perform fast division using two bits at a time, but due to a production error, they were missing part of the table. Those chips would give almost-but-not-correct answers when dividing by 3 but were fine for everything else. It's just really hard to validate whether or not a CPU is 100% working correctly.)
standard TTL communication coming from outside with a JST 2mm connector
It's possible that received interference on these communications lines, such as a momentary spike of high voltage or negative voltage, could cause disruption similar to power supply disruption. If any of the I/O pins exceeds the power supply, then several of the internal PN junctions which would normally be reverse-biased, suddenly become forward-biased. This drags the power supply voltage up through the higher-voltage I/O pin, and internal currents flow where they should not, causing unpredictable behavior.
It's possible that some kind of ESD-related or EMC-related event caused interference to normal operation. If there are big motors, solenoids, relays, or other heavy inductive loads in the system, those can be a source of self-interference. Most real-world microcontroller systems are controlling something.
We have a metal shielded enclosure to the ground and standard TTL communication coming from outside with a JST 2mm connector.
The metal shielded enclosure is a good start for EMC. But connecting TTL logic level signals directly from outside the metal enclosure definitely could be a source of EMC "received interference" vulnerability. The conventional wisdom is to add TVS diodes ("transorbs") right at the entry point inside the shield, to guard against high voltage, then some Zener diodes (with series resistors) to guard against medium voltage too low to trigger the TVS, then some reverse-biased Schottky clamp diodes to guard against low voltages that exceed supply or ground rail. Unfortunately that's only a starting point. A lot depends on what exactly could be the source of the interference.
Sometimes it's hard to tell whether or not a chip is damaged. ESD events are very tricky. There are internal protection circuits (such as SCR) that trigger in response to high ESD voltage, but they don't always trigger at low to medium ESD voltages. ESD testing always uses a standard such as "human body model" or "machine model", but in the wild, the actual ESD voltage is harder to predict. Could depend on the weather (humidity) as well as triboelectric effects from the materials in the floor/shoes/clothing. Sometimes the static electric "spark" is strong enough to be felt, but sometimes not.
