You are also trying to associate TDD with religion in an attempt to make it seem bad. This is one of the criticisms in the posting and it seems sort of fair.
this is the important part of the sentence: he's actively admitting that TDD may not be the best thing, but it's the best thing he knows, but if you have something else that is at least "as effective as TDD", than go ahead and and to the other thing. He just means that, paraphrasing, `you should feel bad if you are not being as effective as possible, and TDD is the only way I know of of being so effective`.
"Uncle Bob" seems like a pretty open minded guy, but his communicative style make lots of people really misunderstand what he says. DHH otoh is very good at sending his message across to "high energy" type of people that want a "strong punch" and don't have time to carefully read every word of an argument and digest its meaning... this is probably your "type", so this is why you like DHH's message more, but both are smart guys and both of their arguments are valid in different contexts :)
(and generally speaking, I think "Uncle Bob"'s advice is more valuable to mediocre programmers than DHH's, as it imposes a mindset that limits "the damage one can do" :) )
" If you aren't doing <a method to verify quality day-to-day work>, or something as effective as <a method to verify quality day-to-day work>, then you should feel bad."
The point is that if you're not doing TDD, you should be doing something that's as effective (or more) as TDD. Otherwise you're just doing shitty work.
IOW, you can disagree with Bob about TDD being the most effective way to verify quality, but you still need to verify quality.
I'm not sure about you, but I think people that do shitty work should feel bad. That's not cultish, that's just basic professionalism.
People have been verifying software since software was created.
Manual verification is indeed more complicated, slow and prone to failure but it's not worthless as the TDD people paint it, not TDD is the holy grail (it has a lot of deficiencies that seem to be ignored by the TDD people)
Also, UBob is lashing other testing DHH proposes in the text, but guess what, it's meant to test what TDD doesn't reach.
You can have 100% coverage of your tests with TDD and still have a bug.
"Manual verification is indeed more complicated, slow and prone to failure but it's not worthless"
Manual vs. automated is a whole other discussion, rather separate from TDD.
Manual test scripts are not worthless, but are certainly an indication your project is either (a) very small scale or simple or (b) going to take a very long time to complete and be prone to regressions.
TDD is about the benefits derived when you write your test case before your code, and also the design implications of doing so.
"You can have 100% coverage of your tests with TDD and still have a bug."
Obviously. But the probability of your codebase having defects goes down drastically with higher code coverage.
You could take the new radical approach of "don't test, just ship", but that requires a very specific organizational culture and risk profile.