It may help to stop thinking of it being used specifically for recursion - there can be tail calls between several functions. In cases where TCO is applicable, function A calls B, and B calls C, but since B isn't doing anything to the result, C can return directly to A. This is transitive - D, E, F, ... could all return to A as well, in constant space. It "goto"s the next function (but with arguments), and returning and popping the results off the call stack is deferred.

Rather than going into fairly abstract examples* , TCO is useful because it allows more things to be expressed in terms of function calls, without having to worry about blowing the stack. While the discussion surrounding them can be a bit overly academic, they ultimately matter because they can help make code clearer. (Not always, but you can implement clearer looping mechanisms on top of them.) A tail call is like a de-fanged goto.

* Just one: Parsing by implementing a finite state machine in function calls. See Shriram Krishnamurthi's "The Swine Before Perl" (http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...).

While the stacktrace no longer records intermediate steps, (and thus loses info useful for debugging), language implementations can typically hook tail calls to save the information when a debugging flag is on. It's not as big a problem in practice as some people think.