This bug was reported to the Debian BTS.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212195

If there's a transient problem with gconf when starting up (as happens
from time to time when running unstable!), some panel inhabitants can
not be started.  When the panel then reports each of these separately
and offers to delete them, "Delete" is the default button.

This worries me for several reasons:

1. If the problem persists, there's always still time to delete the 
offending items.  If it doesn't, deleting them is a very bad choice!

2. The dialog in my case (metacity) steals the window focus.  I might
be pressing "enter" in response to something else just as the dialog
pops up.  And this particular dialog appears to be a herd animal!
A simple confirmation request takes so little information content from
the user that the risk of an accidental "confirmation" is pretty big.
This goes even for mouse interaction BTW: In my case the "Delete" 
button appeared in exactly the same place as a perfectly safe "OK" 
button from a previous dialog that I was about to click on.

3. Normally I'd expect to delete things like configuration items in a
sequence of: ((0) problem report), (1) user command, (2) confirmation 
dialog, (3) user response.  In this case it's (1) combined problem
report & confirmation dialog, (2) user response.  Confirmation requests
are even more important if interaction is not user-initiated.  

4. Onsetting dialog poisoning makes for easy mistakes.  (It would help
if all failed panel inhabitants could be reported collectively in a
single dialog.)