There's a couple fronts to address this on:

1. The need for compile-time polymorphism vs. runtime polymorphism.
2. The desire for generalization and flexibility.

For 1, you generally don't have a choice -- compile time polymorphism is either what you want, or not what you want. Its the solution to your problem, or it isn't. It presents a different set of compositional properties than run-time polymorphism. Knowing the difference will shed a great deal of light on the value of templates and generic programming in general.

For 2, the choice is often subjective -- is it less work to be generic now, or to duplicate some code in some cases? Which is easier for your team to understand? How far is your compiler willing to support your templating efforts (ie, does it support partial template specialization or not)? In general, I would agree that your observation in this light is largely correct: It's "factually" better to be generic, but in practice most code isn't re-used. You just need to be able to judge which code falls into which camp. Containers and algorithms are great candidates for example (such as in the C++ standard library) but it probably doesn't make much sense to templatize classes that represent logic (in the sense of decision-making, interaction and control, more than formal algorithms).

I think that when someone thinks about using templates, he starts to think as good programmer
It is not good to push on it and write code to have templates...
Sometimes I look back at my code and I immediately see that "this would perfectly fit for template" and I do it...

Templates are primarily a tool for reducing code duplication.
Use them mainly when you wish to reduce code duplication, where simply putting the duplicated code into a function wont work becuase the types differ.

No, mostly not; and I don't have the feeling I'd miss something. But yeah, I do use STL and other template libs and hate them when it comes to debugging.

Actually we are and there is an "interesting" construct full of templates. It's making some parts of the work a lot easier, but anyone not familiar with templates will have a hard time and tends to be in trouble when it doesn't compile. And since this construct has tons of little "intermediate classes" that all get their own RTTI it's one of the cases where they do bloat the coat (essentially we have the same information as an earlier version but the binary is 10x bigger in size).

Apart from that one problem with templates like with any other tool is that when you discover it (or find new uses) you are in danger of wanting to apply it to everything. Have a look at "Modern C++ Design" and if you thought they are only good for generic functions, you might be surprised... and wonder where "using" templates ends and "abusing" them begins (if there is such a thing in programming). I still think that being able to use templates to eventually write "TypeBySize<2, Unsigned>" and having it work for most platforms without endless #ifdef's is neat (though redundant with stdint.h). Though almost everything else I used them for in the past can already be found in boost in a much nicer, more flexible and better tested form. I'm sure there is some lib that simulates my "binary stream" (which mostly boils down to hide memcpy in/out of a buffer behind stream syntax).

Sometimes they are the best way and sometimes they look cool but add little. How much you should use them depends on what you're doing. For example: are there any specific parts of the code where they feel that you should be using more templates? What are they? Is it about making something generic with lots of extra effort that will most likely never be used in any other way for the next 20 years? Or about making a simple "min" take more than just ints?

I write a good few template functions, but only a couple of template classes. The overall level of template code is low, though the amount of code written in terms of existing template functions/classes, as others have mentioned, is considerably higher.