Which are the causes for bricking a working ATMega328?

A sketch can theoretically NOT overwrite the flash. Only the bootloader (or a device programmer) can write flash. (I'll assume you haven't installed that bootloader upgrade that allows calling it to write flash.)

  1. Corrupt the linker

I'm not sure what that means. "The linker" is normally one of the build tools, and nothing a build tool does should brick an AVR.

  1. Configuration bits

There should be no way to change the configuration bits ("fuses") without a device programmer. Even the bootloader can't do it.

The most common way to "brick" an AVR with a device programmer is to mis-configure the clock. Once configured for a clock that isn't there (say: "external oscillator" instead of "external crystal"), you're in trouble, because the clock is needed to do additional programming.
Also - turning on "debugWire" will stop ISP from working.

  1. Have bad hardware state, which causes brown out or reset event
  2. Kill a section of flash from too many writes.
  3. Use incorrect voltage for frequency.

These should be temporary issues that don't brick the chip. (Well, I guess if you connect Vcc to 48V, that would result in permanent damage.)

  1. Blow up pins.
  2. Put noise on programming lines.
  3. Watchdog (Bootloader could block this.)

These are more likely. In particular, there's a know bug in the old bootloader that would send chips into a watchdog reboot loop, and a hardware bug in some old boards (missing diode on RESET) that can cause the auto-reset feature to put the chip into HV programming mode. ( Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED )