Rebutting the specific points:
No concept is harmful in itself.
It's not the concept that's harmful. Inappropriate use of a concept, tool, or technique can be very dangerous indeed.
Asserting one of the aforementioned is harmful is similar to saying
that "a hammer is dangerous"
You seem pretty sure about that. Have you considered that in some cases the advice you get might be more like saying "a poorly engineered piece of artillary is dangerous?" In other words, while there may be legitimate arguments for using a feature that many consider "dangerous," the arguments for avoiding that feature may be well considered and substantially stronger than the arguments for.
It so happens that I really love goto, singleton, and reflection.
My advice here would be to avoid mentioning that as an argument in favor of using those features, particularly in an interview or code review. Because really: What's love got to do with it?
Beyond that, you should devote some thought to why you really love goto, singleton, and reflection. Is it because they're convenient? Can you appreciate the kinds of problems that each can cause? If you understand both the the benefits and the risks, you're in a pretty good position to make an informed decision. However, you should also make sure that you understand the risks from other people's perspectives and be able to work around them. To an organization with a large code base, the benefit of banning use of goto anywhere in their code may outweigh the benefit of using it in the occasional spots where it might help. You need to be able to deal with that restriction.
So I pose a question to the open minded amongst us, how do we deal
with it when people regurgitate this dogma?
You're not winning any points for objectivity here.
What if it's a really good place to use a singleton, goto, or
reflection, and then some non-thinker comes along and flames me for
If you can make a valid argument that your implementation is superior according to whatever metrics and standards are in play, then you should get to do things your way. If you lose the argument, then you should willingly adopt the superior method. And be careful tossing phrases like "non-thinker" around lest you be put in that very same box.
Example 1: Consider for a moment that you found a library called flimflamlib. It seems to do exactly what you need, and after reading the documentation you totally grok the whole concept behind the library. A few days after you start using flimflamlib in all your stuff, several senior developers tell you that they've looked at flimflamlib, and while they agree that it appears to be both highly useful and highly useable, it is in fact not just a piece of junk, but an unfixable and dangerous piece of junk.
What do you do? Do you label these nay-sayers non-thinking half-wits and disregard their advice? Do you go on using flimflamlib because, after all, it does what you want and you don't see why these scaredy cats should make you do things the hard way? Or do you take a hard look at flimflamlib, try to see things from their perspective, and reassess your use of it?
Example 2: Many companies have coding standards and/or style guides. Sometimes, these documents impose blanket prohibitions on certain techniques, patterns, features, etc. Google's C++ Style Guide is a great example. It says things like "We do not use Run-Time Type Information" and "We do not use C++ exceptions". It doesn't say "carefully consider the risk of _ and use your best judgement," but that doesn't mean that the document is dogmatic. Indeed, each rule in the document is accompanied by the rationale for the rule. You're welcome to disagree with the rules, but you're not welcome to disregard the rules when you're writing code for the organization.
In summary: Are there any practices that you would consider to be genuinely dangerous and/or ill-advised? What would you say to someone who disagrees with you?