"Type-sensitive" code is encouraged when using the functional style, where you treat objects as dumb "bags of data" that have no inherent functionality of their own. It's still discouraged when following an object-oriented "smart objects" pattern.
I guess in a dynamic functional language you'd probably avoid doing this type of contact-oriented stuff, but you'd rather pass a callback at the last point rather than check type of what you got passed.
And that would have been a good example! contrary to the one in the docs.
Pattern matching for checking fields of things of the same type is a good use. Pattern matching when checking your parameters type? bad.
> The nice thing about it is the compiler can assert that your match is exhaustive
If you pass a new Shape object for which you forgot to implement a new case in the pattern matcher, you just get the default case, which is wrong, but the compiler can't know that. Now have the function argument ask for something that implements IArea interface and if you don't implement getArea() in your new Shape class, the compiler will know.