It all depends on how specific you want to be / how much you want to assert before calling a function.

if (myObject)

Can an object or function ever fail this simple test?

No, the only values that do not pass an if clause are false, 0, "", NaN, undefined and null. These are all primitives. Objects (including functions) will always pass an if clause.

if (myObject != undefined)

When is this better than the previous test?

If you want to check whether a value is "meaningful", i.e. not undefined or null. For example,

if(numberInputtedByUser) {
    // do something with inputted number
}

will fail the if clause if the number is 0, while you probably want 0 to be allowed. In such case, != undefined is a slightly better check.

if (typeof(myObject) == 'object')

This appears to be the original way of calling type of, but some people say that typeof is a keyword and not a function. Also, why not one of the simpler tests?

It is a keyword. You can call it in a function-like fashion, though. In its most bare form you can use typeof like this:

typeof myObject

You can, however, add (extraneous) parens since they don't mean anything:

typeof (myObject)

Just like you can do:

(myObject).key

or even:

(((myObject))).key

And you can then remove the space after the typeof if you want, resulting in something that looks like a function call.

As to why to use typeof - you can be even more certain of the type of variable. With the if(...) test, the values that pass can be all kind of things - basically everything except the list I posted above. With if(... != undefined), you allow even more to be passed. With if(typeof ... == 'object'), you really only allow objects which might be necessary depending on what you're processing.

if ( typeof myObject.function !== undefined ) {

One post said to alway use === or !== as it differentiates between null and undefined. Is this ever important in practice?

=== is really preferred over ==. While differentiating between null and undefined is not always necessary, it is a very good practice to save yourself from the results of quirks like 0 == ''. If you want to check whether a number is 0, then === 0 is the way to go, since == 0 also allows for an empty string (which you might not expect and probably don't want). Even in cases == doesn't cause quirks, you'd be better off using === at all times for consistency and avoiding surprising bugs.

try {
    node.addEventListener(...)
} 
catch(err) {
    node.attachEvent(...)
}

This is of course possible and very straight-forward. Note however that try catch is said to be slow. Moreover, you don't really account for why it fails. It's a bit simple-minded (but may work fine).

if (typeof node.addEventListener == "function")

but will this ever yield a different result than plain

if (node.addEventListener)

Yes, like I said above, the first only passes functions whilst the second allows anything except that list of "falsy" values. One could add Node.addEventListener = 123, and it will pass the if clause in the second case. But IE fails to give a correct typeof result:

typeof alert !== "function"

I bet the same goes for addEventListener so you'd still be avoiding that function even if it exists.

In the end, I would just use a simple if clause. Of course this will fail when you add weird things like Node.addEventListener = 123, but then again you're bound to expect weird things happen.