That paper was interesting, worth signing up to read.
I thought I was going to disagree, because it started with some bold words, but ended up at a fairly mild conclusion: That practices should be evaluated in the context of the business requirements of the project. I.e. look at the real cost of failures and balance that with the cost of practices designed to minimize failure.
Obviously, I can't speak for everybody here, but are there people that think otherwise? Preventing 90% of issues is fairly easy. Preventing 99% is hard. 99.9% is incredibly hard, and so on and so on. Obviously, you have to stop somewhere. And to decide where exactly to stop, you have to sit and think what the real cost of failure is. Will a small fraction of customers be driven away by the bug? Will embedded systems need to be recalled? I think that everybody goes through this "How good does it have to be, how much effort will it take to get there" evaluation when thinking about a project.
Talking specifically about the Test::* suite, I haven't seen zealotry here. I see comments like "Use of Test::Whatever is very beneficial when I use it." I've been taking that to mean "I use it where it makes sense, but not where it isn't an economic use of my time." I may be way off, but I don't think people are advocating cargo-culting use of Test::* modules into all projects.