But I agree that you should know what it gives you and why and when it is important. There are many case where you end up with TCO as a result of a solution you chose for other reasons. For example often when you carry values around in accumulators you end up with a tail-recursive function even if this was not the goal.
And the efficiency always needs to be measured. Saving stack can however save you gc even if you may not save memory.
The prolog example is maybe be tail-recursive depending on the implementation, but you pay for it with memory. There is a hole in the list, sort of anyway as it refers to an unbound logical variable which is not free.
No, erlang does not have “tail recursion modulo cons”. They optimised the stack usage but it is still not TR. What they mean is that if you do the TR version which then does a lists:reverse then yes you will save stack as lists:reverse is TR, or implemented in C. But you will pay for it by building the list twice, once in TR function and once in lists:reverse to get it in the right order. Take your pick, more stack and less heap or less stack and more heap. Pest eller kolera.
I just updated the post after all this time (somebody commented) - when the list size is increased it seems like tail-recursive functions get faster again. E.g. instead of the original 10_000 element list I used a 10_000_000 list and recorded the benchmarking results here. The tail-recursive functions are almost twice as fast as the body-recursive version and the standard library version.
So, always benchmark your own use case and it’s time that I give benchee its multiple inputs feature 
(sorry for doing a little resurrection but I thought this was a rather important point to raise here)
And more resurrection, I used benchee 1.0 to take this (as one of the “original” benchee benchmarks) up for a spin to see how things have improved and found some peculiar behaviour: Revisiting “Tail Call Optimization in Elixir & Erlang” with benchee 1.0 – Journeys of a not so young anymore Software Engineer