I think I'm still not catching your meaning of "elegant." Efficient code, to me, is elegant. As such, I would disagree that elegant code is a bad thing.
Ok, let me get away from that word. "Elegant" comes from a particular person I had the displeasure of working with for a short while. In his opinion, if code was not obfusciated it was not "elegant". I see that without that context it can easily be taken as meaning something else. I would I that sense agree that a good solid solution could be called "elegant".

I have experienced several "programmers" that bragged about a piece of code that was, in their own opinion, very "elegant/clever/smart" and just had a little bug to be resolved (that never got resolved). Even worse, some was used.

Now this may be where I differ. If the programmer is showing off good code, then he has every right to "show off" and brag about this code.
Absolutely. The "show off" I refer to is not showing off with good code but examples like the above.

Elsewhere in this thread you mentioned that you saw the 8052.com challenges as a good place to show off without hurting anyone--I would disagree: If you can write solid code that does in 50 instruction cycles what another routine does in 80, then that's a good thing.
again, I agree; however going one step too far often, rather than solid code lead to code that will have one "stupid" exception. As an example, I have, myself, in a case of extreme speed requirements - where "my rules" had to be broken had it happen that a "linker move" of a routine made a "pesky little mistake" come to light that would not be a problem had the buffer not been located just there. Such issues have a tendency to show up at your most critical customer at the most inconvenient time ref Murphy's Law. Of course, this example, fortunately showed up at the development table.

Erik