The major advantage of TRO is that it's (often much) easier to implement: a purely local analysis can inspect the final statement and convert the function body to a loop. In all other technical respects, general TCO is strictly better, only harder, though the performance envelope can be worse on some platforms.
The most common use case that TRO misses is immediate mutual recursion. Two functions bouncing back and forth to one another is a common functional pattern that isn't detected by a pure tail recursion analysis. This is common enough that occasionally a mutual tail-recursion optimisation is implemented without going all the way to general TCO, though the same effect can be accomplished by inlining one of the functions and applying TRO to the result.
A major—perhaps the main—benefit of general tail-call optimisation is enabling code in continuation-passing style or similar approaches, where (very) long chains of unrelated functions calling each other are expected. Without TCO either manual or generated CPS code tends to fall over at even moderate complexity when it runs out of stack space. Solely optimising tail recursion is no help in this case, though the continuation-passing approach isn't something that every language will care about.
While tail recursion can always reuse the function's existing activation record, full TCO has to handle the next function's being bigger or smaller, which can be complex on some platforms. The extra work may make tail calls more expensive than otherwise, so the benefits would only appear in the deep recursion cases that couldn't otherwise run at all. For a language that is interpreted on top of a higher-level language with reified stack frames this cost is likely to be negligible if extra allocations can be eliminated, while at the machine level it is liable to be comparatively expensive, and on virtual machines it may not be permitted at all. In the latter case the decision may have been made for you.
Often performance is not a particular goal of these languages, and the purpose is to enable the programming model, so small overheads can be acceptable in any case. The implementation difficulty otherwise is generally not so high above tail recursion, for functional languages at least.
One of the significant ergonomic drawbacks of any tail-call optimisation is in error reporting that loses track of the call stack and cannot report how the program reached the point of failure. With only self-recursive tail calls, this is reduced somewhat, as the final frame can be marked as looping and the stack that reached the function in the first place stays intact. The typical mitigation in tail-call-optimised systems that want to address this is a ring buffer of recent function calls, which is unhelpful precisely in recursive cases.
Tail call optimisation that doesn't always work, for example if it excludes functions using certain features, can make for unexpected surprise failures. If it relies on the functions being in the same module then otherwise-simple refactorings become difficult for non-obvious reasons. This is likely to be more of an issue for the "clever" middle-ground solutions than either full TCO or TRO.
In a system that doesn't expect extremely long function call chains, full tail-call optimisation probably isn't worth the initial effort in terms of gained expressivity, but expectations can be wrong. In a Scheme, where programming in that style is the norm, it's essential.