The article does not describe the primary issue with using templates: that using templates leads to hard-to-manage non-modular code. Templates have their uses, but a big problem is that any change in template code means recompile of any code that uses it. Additionally, the interface contract is not well defined. Adopting an interface/inheritance approach generally leads to much more maintainable code.

And yes, you can use namespaces and careful template programming to give some modularity to the code, but in the end, if one code line change in one template header, that is used by multiple other template headers, and in turn by multiple libraries, means you have to recompile thousands of files and dozens of libraries, this is a very big price to pay.

The article starts with function templates, which are tricky, with function overrides interfering with template instantiations. The article seems oblivious to this issue.

  "void PrintTwice(const TYPE& data)"

If you are going to make a function template that ought to work with primitive types accepts a primitive type, const& may not be that simple. You may want to write a separate template implementation (and choose between them using enable_if<> and type_traits), because you don't want to take a pointer/reference to an int if you don't have to.

"You should have noticed that I used typename, instead of class. No, it is not required to use typename keyword if a function returning something. For template programming, these two keywords are very much the same."

I have generally used <class X> rather than <typename X>, following a comment by David Abrahams to that effect on the boost list a long time ago. I think it has to do with the fact that typename does have multiple meanings inside the angle brackets.

  "int tSum = int();"

I think this code is problematic.