Duff's advice on avoiding if/else is echoed in a functional programming context by CMU's Bob Harper, who writes, "[A]void if-then-else entirely, and instead use only case analysis for branching..."
http://existentialtype.wordpress.com/2011/04/17/some-advice-...
Uhh, not same reasons. Harper is an ML hacker, he wants to avoid IFs to encourage generic programming and pattern matching. Adding a new branch to an if clause requires some nesting, adding a branch to a case/cond is just one entry of many. After that, pattern matching becomes natural an you tend to see a function not as a single wholesome "body", but a family of mappings.
Again, switch, duff's device & other computed-goto hacks are "constructs", a chunk of "decision" code that sits in the middle of the page directing traffic. Pattern-matching is far more sublime than that: along with manifesting itself as a visual construct, it can also hide in the head of the function, cozzying up with its parameters, and also in binding/assignment forms.
A distant, but weaker cousin of pattern-matching is destructuring, more common in Lisps.
