FWIW, I wouldn't suggest the term "defensive coding" as the opposite to "fail fast". It's very similar to the established term "defensive programming", which IMHO is more about designing systems to make fewer assumptions. How you then handle a situation where you do detect that some expectation has not been met, including the fail-fast strategy, seems like a related but separate issue.
Terminology aside, though, I agree with much of what you say. The idea that it's generally acceptable for buggy code to just crash out seems to be making an unwelcome return recently, often among the same kinds of developers who don't like big design up front or formal software architecture because they want everything to be done incrementally and organically, and in the case of web apps specifically, often among developers who also consider code that runs for a year or two to be long-lived anyway.
With defensive coding I indeed meant defensive programming. You always want to fail fast (faster also means that you can fix more bugs), but this is often interpreted as "fail hard": no prevention or mitigation what so ever. In this sense I meant it is the opposite of defensive programming.
What I notice is that developers who also have a background in statically typed (system) languages, are much more disciplined when it comes to defensive programming and logging/error handling. (I'm afraid this also correlates with age).
BTW, I like your description, "designing systems to make fewer assumptions", for defensive programming!
Terminology aside, though, I agree with much of what you say. The idea that it's generally acceptable for buggy code to just crash out seems to be making an unwelcome return recently, often among the same kinds of developers who don't like big design up front or formal software architecture because they want everything to be done incrementally and organically, and in the case of web apps specifically, often among developers who also consider code that runs for a year or two to be long-lived anyway.