user3237: When the Leonardo was introduced, I think, I've read some articles about being cautious to do some things, that could cause it to not load any new sketches any more, so one has to rewrite the bootloader. Because I plan to use power-saving options, e.g. to disable unused hardware components like USB port, I fear to do something wrong.
One Leonardo-delicacy I've found so far:

if interrupts are disabled, uploading new sketches fails unless one presses the Reset button as soon as the Arduino IDE is showing "Uploading..."

What stuff (except of the usual hardware-related thinks like connecting output-configured pins to fixed potentials) could damage the controller or require to reflash the Leonardo with a fresh bootloader?

user1566: If you upload a program that changes the speed of the USB core it would be almost bricked. What would happen is this:

Power on, boot loader starts, USB device enumerated on PC.
A few second later program start, USB core speed changed, USB device disappears from PC

The issue here is that not only do you have to hit reset to program, after the reset you have to quickly select the right com port and then upload before the program starts. 
The Redbearlab Blend Micro requires a USB core speed to be set in the user program. In their setup instructions there is a step to edit the Arduino main.cpp and add a section to do so. If this step is missed, the above problem happens.

user3713: I managed to brickwall an ATMega128RFA1. The bootloader, and the software I uploaded in it, were working fine. But it was impossible to erase/write the ROM.
After checking for what have happened, I discovered in the datasheet that some fuses in the AVR core are intended to protect accidental writing on the ROM. Some kind of security fuses.
I never found the bug which wrote in these bytes (as it was a really big program and we were 3 peoples involved in the coding) but yeah, we just blew a fuse and lost an MCU because of a bug.
As for the leonardo, several things could happen, but none of these can brickwall your board unless you blow one of this protection fuse.

user86: It is possible, with some really clever code, to exploit the bootloader to overwrite itself.
Excerpt:

The solution is actually conceptually fairly simple. A bootloader, by
  its very nature is designed to download new firmware to the device.
  Therefore it will contain at least one spm instruction. Because the
  spm configuration register must be written no more than 4 cycles
  before the spm instruction it means there are very few sequences that
  practically occur: just sts, spm or out, spm sequences. So, all you
  need to is find the sequence in the bootloader section; set up the
  right registers and call it.
However, it turned out there was a major problem with that too. The
  V-USB self-programming bootloader's spm instructions aren't a neat
  little routine, but are inlined into the main code; so calling it
  would just cause the AVR to crash as it tried to execute the rest of
  the V-USB bootloader.
Nasty, but again there's a solution. By using a timer clocked at the
  CPU frequency (which is easy on an AVR), you can create a routine in
  assembler which sets up the registers for the Bootloader's out, spm
  sequence; calls it and just at the moment when it's executed the first
  cycle of the spm itself, the timer interrupt goes off and the AVR
  should jump to your interrupt routine (in Application space). The
  interrupt routine pops the bootloader address and then returns to the
  previous code - which is the routine that sets up the out, spm
  sequence. This should work, because when you apply spm instructions to
  the bootloader section the CPU is halted until it's complete.

So basically, you can do some fancy programming, and get the bootloader to hose itself, rendering the MCU useless without a dedicated programmer.

3237: <p>When the Leonardo was introduced, I think, I've read some articles about being cautious to do some things, that could cause it to not load any new sketches any more, so one has to rewrite the bootloader. Because I plan to use power-saving options, e.g. to disable unused hardware components like USB port, I fear to do something wrong.</p>

<p>One Leonardo-delicacy I've found so far:</p>

<ul>
<li>if interrupts are disabled, uploading new sketches fails unless one presses the Reset button as soon as the Arduino IDE is showing "Uploading..."</li>
</ul>

<p>What stuff (except of the usual hardware-related thinks like connecting output-configured pins to fixed potentials) could damage the controller or require to reflash the Leonardo with a fresh bootloader?</p>
 1566: <p>If you upload a program that changes the speed of the USB core it would be almost bricked. What would happen is this:</p>

<ol>
<li>Power on, boot loader starts, USB device enumerated on PC.</li>
<li>A few second later program start, USB core speed changed, USB device disappears from PC</li>
</ol>

<p>The issue here is that not only do you have to hit reset to program, after the reset you have to quickly select the right com port and then upload before the program starts. </p>

<p>The Redbearlab Blend Micro requires a USB core speed to be set in the user program. In their setup instructions there is a step to edit the Arduino main.cpp and add a section to do so. If this step is missed, the above problem happens.</p>
 3713: <p>I managed to brickwall an ATMega128RFA1. The bootloader, and the software I uploaded in it, were working fine. But it was impossible to erase/write the ROM.</p>

<p>After checking for what have happened, I discovered in the datasheet that some fuses in the AVR core are intended to protect accidental writing on the ROM. Some kind of security fuses.</p>

<p>I never found the bug which wrote in these bytes (as it was a really big program and we were 3 peoples involved in the coding) but yeah, we just blew a fuse and lost an MCU because of a bug.</p>

<p>As for the leonardo, several things could happen, but none of these can brickwall your board unless you blow one of this protection fuse.</p>
 86: <p>It is possible, <a href="http://oneweekwonder.blogspot.co.uk/2014/07/bootjacker-amazing-avr-bootloader-hack.html" rel="nofollow">with some really clever code</a>, to exploit the bootloader to overwrite itself.</p>

<p>Excerpt:</p>

<blockquote>
  <p>The solution is actually conceptually fairly simple. A bootloader, by
  its very nature is designed to download new firmware to the device.
  Therefore it will contain at least one spm instruction. Because the
  spm configuration register must be written no more than 4 cycles
  before the spm instruction it means there are very few sequences that
  practically occur: just sts, spm or out, spm sequences. So, all you
  need to is find the sequence in the bootloader section; set up the
  right registers and call it.</p>
  
  <p>However, it turned out there was a major problem with that too. The
  V-USB self-programming bootloader's spm instructions aren't a neat
  little routine, but are inlined into the main code; so calling it
  would just cause the AVR to crash as it tried to execute the rest of
  the V-USB bootloader.</p>
  
  <p>Nasty, but again there's a solution. By using a timer clocked at the
  CPU frequency (which is easy on an AVR), you can create a routine in
  assembler which sets up the registers for the Bootloader's out, spm
  sequence; calls it and just at the moment when it's executed the first
  cycle of the spm itself, the timer interrupt goes off and the AVR
  should jump to your interrupt routine (in Application space). The
  interrupt routine pops the bootloader address and then returns to the
  previous code - which is the routine that sets up the out, spm
  sequence. This should work, because when you apply spm instructions to
  the bootloader section the CPU is halted until it's complete.</p>
</blockquote>

<p>So basically, you can do some fancy programming, and get the bootloader to hose itself, rendering the MCU useless without a dedicated programmer.</p>
