Defensive programming, YU so popular?

This term can have a lot of meanings. Everyone likes to attribute all the good thing to  a term they like while saying the bad things are misinterpretations or don't belong to that term altogether (Agile, anyone?). Usually when I hear people mentioning defensive coding, this is along the following lines, and this is what I take it for:

Defensive coding is doing everything possible to not make a fool of yourself.

Looks like people believe this is good thing, but to me it looks potentially very devious. This is like curing symptoms, not a problem. Covering your ass may be good for you in the short term, but definitely not for your team.

While defensive coding may contain often useful practices such as validating data coming from the external system, other more questionable practices tend to be associated to it ("check everything for null", "log all random things you can think of" ). To me, these are just Good practices, and Bad practices (in some context ofc.) - and defensive programming seems to contain practices from both of those sets.

Now there is another term, Offensive programming, which basically says, when you fail, scream as loud as you can, so that everyone else knows. This looks much more appealing to me. It looks like programming model Erlang advocates, where if worker fails, it does not attempt any tricks to recover, it just exits. It is responsibility of that worker's supervisor to decide what should be done in face of this failure.

There is but one place where defensive coding makes sense. And that place is most important of all in software. It is Production. Here, crashing the system is the worst thing that could possibly happen. It is often much worse than corrupting data, hiding the fact that something was not accomplished, etc. This is lying to your user. But if you lie rarely enough so that user doesn't notice it, this is better than telling this software is full of bugs by crashing and thus interrupting workflow.

So, defensive coding is bad for you (in the long term). It is bad for your team. It seems to be good for your business. Yet, I feel it is a sorry state of software development, where writing crap, and then defending against the crap you and your colleagues wrote is regarded as proper way of coding. Offensive coding raises the bar higher, and I want to believe it will be a way of doing things sometime in the future.