Can any method that uses recursion be written as tail-recursion?
You can't rewrite all your recursive calls as tail recursive calls but you can rewrite your program in continuation passing style which is closely related and has the feature that every procedure call is a tail call (just not necessarily a tail recursive call.)
The way you do this is by recognizing that every time you make a procedure call you are implicitly specifying a return point. Then you split your procedure into multiple procedures, each starting at a return point and ending at the next call point. Continuation-passing style essentially makes the stack explicit. Once the stack is explicit it is easier to apply certain optimization (like tail recursion elimination).
procedure depth_first(t): if not-null(t): l = depth_first(t->left) r = depth_first(t->right) return l + r + 1 else: return 0
The first step is to make every procedure take an extra parameter,
k which is a continuation procedure (a procedure which you return to by calling it with the return value as its parameter). Then you turn the procedure "inside out":
procedure depth_first(t, k): if not-null(t): depth_first(t->left, lambda(l): depth_first(t->right, lambda(r): k(l + r + 1) else: k(0)
Should you do it? Well, if you're a compiler and you want to perform tail-recursion elimination optimizations, or generate machine code, then yes. Otherwise probably not. One of the joys of high level languages is that they have syntax that makes continuations much easier for humans to read and understand. Let the compiler do what it's best at and concentrate on writing maintainable code.
Good practice, however understood, does have various style implications, and encourages some programming paradigms over others, but I do not know that using tail recursion is part of it. Some people do prefer recursive style for various reasons, and that may result in a lot of tail recursion. That used to be very common in languages like Lisp or Scheme, and their programmers were probably the first to notice the issue below.
Tail recursion was identified originally (afaik) as a situation where compilers could speed up execution by replacing them by a loop, and saving on stack management. It is only what the name says: a tail recursion, i.e. a recursive call that is the last thing done by the function before returning.
It is a property of the source code. Object code does not have recursion (other than possibly for high level virtual machines, not for tangible hardware), only loops and memory management. Thus no implementation of anything is written as recursion of any kind, including tail recursion.
If that sentence was supposed to ask whether a non-tail recursion can be compiled in the same way as a tail recursion is compiled, the answer is no because non-tail recursion requires preserving existing execution environments (so-called activation blocks) on the stack (usually), for whatever code remains to be executed on return. Only tail recursion can avoid that, since it will not have anything to do on return (well, it is the general idea, some details are skipped).
Of course, all recursions can be transformed into loops with some effort. That is precisely what the compiler does, since object code has no recursion. Then the program has no recursions that are not tail recursions, not having any at all (as David Richerby remarked). Furthermore, translating back in a language rich enough, a loop can be replaced by a tail recursion (skipping many details), so that you can have it all with tail recursion. But it does you no good. It is only an intellectual exercise.
I cannot say this reply was not influenced by David Richerby very good comment.
Given the amount of wrong info dispensed in the other answers, I strongly invite you [collectively] to read Specification and Transformation of Programs by Helmut A. Partsch; it addresses the topic at length in Chapter 6. Transforming programs (say to turn recursion into tail recursion) is alas not a topic commonly covered in other textbooks.
Briefly: You can turn any function that uses recursion into one that uses only tail recursion. The result may not be very pretty to read though; it's akin to removing a goto, i.e. you will need to encode control decisions as predicates.
If I have time, I'll expand on these points, but realistically it won't happen this weekend.