Funny, I'd say the exact opposite: stick to function statements exclusively.

There's no benefit at all to function expressions, and without hoisting, function expression allow you to call a function before it's declared. (going BOOM!)

It makes more sense if you realize, ALL function declarations (statements, and expressions) are "hoisted" (actually processed first, during what is comparable to the "compile" phase) and all anonymous function are given machine-generated names. So, JavaScript really considers your first example as if it were written:

function _anon_1111 () { console.log("doThis"); };
function doThat() { console.log("doThat"); };
function orThisOther(again) {
    if (again) {
        console.log("orThisOther");
    }
    else {
        console.log("doTheOther");
        orThisOther(true);
    }
}
function _anon_2222() { console.log("anonymous"); }
// example 1 - function expression
var doThis = _anon_1111; 
doThis();
// example 2 - function statement
doThat();
// example 3 - a mix?
var doTheOther = orThisOther;
doTheOther(false);
// example 4 - IIFE
_anon_2222();
    .

So, function definitions are handled during the "compile" phase, followed by the code actually running during the "execution" phase. Using function expressions, you just have that pointless assignment at "runtime".

@James: thanks for the comment. Let em see if I can't elucidate further.

First of all, I guess I didn't state strongly enough that either way -- should a function be declared as a statement or expression -- it is perfectly valid JavaScript. I suppose you are right (although I've never investigated): the compile phase would generate names for function expressions via some non-published randomized naming scheme and then hoist away. My thoughts are not about that, but about defining a practice that one should stick to in one's programming.

Now the thing is hoisting happens with every variable, be it function, number, boolean, object, string, array, whatever. So the first standard practice you learn is to declare your variables first when you are in a function scope. Agreed? In fact, unless you turn that option off, the various lint apps check that. So you get used to (at least I did) to declaring your variables at the top, and generally as a sequence of variables separated by commas and terminated by the ubiquitous semicolon. And of course function expressions are just values for variables, so I put them in that same list. Agreed, I don't have to, but I do.

Another example: returning a function from a function. Sometimes it really is easier to return a function expression, although, agreed, you don't have to.

Another example is when you're declaring some quick off-the-cuff object, say a default configuration object, inside a function. The API allows the user of the function to pass in an other configuration object with values that should be used instead. (This design requires the use of an extend function, such as the one in jQuery; a topic for another time.) It is easier to declare methods in this default configuration object as expressions in the normal flow of declaring properties of the object. Agreed you don't have to, but it keeps all the code for the default object together. Here's an example from the jQuery code:

jQuery.extend({
 // Unique for each copy of jQuery on the page
 expando: "jQuery" + ( version + Math.random() ).replace( /\D/g, "" ),
 // Assume jQuery is ready without the ready module
 isReady: true,
 error: function( msg ) {
  throw new Error( msg );
 },
  // and so on, so forth...

So, all in all, even though each of these examples could be written quite easily with function statements, they are easier to write with expressions. And once you get used to the practice of using expressions, you use them everywhere, since for me anyway they constantly remind me that functions are objects.