Comments by "LoneTech" (@0LoneTech) on "Tail Recursion Explained - Computerphile" video.

@Mad_Elf_0 Yes, it is. In tail recursion, the compiler knows all the variables stay in place, so it is precisely the same code generated as for a simple loop. A loop may be harder to reason about compared to a call which enumerates precisely the values available as arguments.
2
@TheScarvig The reason we pay such attention to tail recursion is that it allows tail call optimization, which is replacing your stack frame with the last call in your function. That can only be done if the return value of your function and your last embedded call is the same. If the tail call is a recursive call, the combination transforms the recursive function to an iteratively looping subprogram. You can perform tail call optimization on mutable array reference quicksort (the original), but it doesn't really gain you anything of note because it only changes the last call; quicksort normally branches into two recursive calls. That said, you could also transform it into a single tail recursive call by having an argument hold the state you used to hold on the stack; i.e. a list of the sublists yet to be sorted.
1
It's different on the stack if tail call optimization is performed. That's because it can outright replace the current stack frame, because the return value of the two calls is the same. As a bonus, tail recursion means we know the two stack frames have the same shape, and can replace the call with a local branch. Thus it's easier than reshuffling the arguments for calling a different function.
1