Or Else What?

So, I'm about to do some development on a project that will be using IBM's RAD7. In prepration, the developers are going to a RAD7 class. During class the instructor is dutifully showing us all the bells and whistles and he does this:

if ( somecondition)
{
return success;
}
else
{
return failure;
}

I thought I'd exhert some independence and remove the else block:

if ( somecondition )
{
return success;
}

return failure;

My code is equivalent to the previous example but I began to wonder how do you know when the 'else' clause is unnecessary? In simple cases like this one, it can be easy to show that it doesn't matter. Is this a case where we can make things less clear by being more explicit? Consider the example that uses the 'else' block; if another programmer were to come along and wanted to add more code, how easy would it be for them to decide whether to put the new line in the 'else' block or after it?
Could that question indicate that the 'else' statement is part of a code smell? I'm not sure what the smell would be called, I'm not entirely convinced that it is even a smell. What keeps bugging (ha!) me is how similiar it is, at least as a symptom, to why one of our code standards is to require braces everywhere even if they are optional. I might look this up in Scott Meyer's C++ books.

NON-STANDARD:

if ( chaporones_are_gone) drink;
cleanup;

STANDARD:

if ( chaporones_are_gone)
{
drink;
}
cleanup;

The braces are the safety-net to keep the programmer from inadvertantly making changes to code that isn't affected by the 'if'. The compiler will never be a replacement for a thinking human and since humans are fallible, it makes sense to develop habits that keep us from burning ourselves. How can we define a rule to keep us from overusing the 'else' clause? My initial attempt was something like "only use an else if the else block contains another if" but that doesn't really do it. Maybe when the condition includes something like 'Do x unless a=1' but

Let's add an alternative activity, dancing. If you converted the condition into English syntax, you could say "The teenagers will dance or drink depending on whether the chaperones are gone; in any event they'll have to clean up." This says we clean up always and isn't really affected by the condition. There are two exclusive activities mentioned. We never do both. What I notice is that the sentence has two verbs and one object. I'm having flashbacks to sentence diagramming from junior high, not pleasant.

This is related to the discussion about using negative logic in conditions. Yes, the order of the 'then' and 'else' blocks won't matter to the compiler but one way makes it easier for humans to read. Eliezer Yudkowsky discusses this in a Bayesian logic article using the example of why story problems can be so hard for students to understand.

In all the efforts to get programmers to use more powerful tools, maybe we can spare some time to hone our logic skills. However much we'd like expect our tools to do more work for us, there are some things that will always be left to the individual. Computers won't gather requirements for you. Humans can parse the customers requests and know what to take literally or when to use context to help with the interpretation. A sound foundation in the English language can be a powerful tool in the developers toolkit.