This may not be a big deal, but I can see how it might be useful every once in a while. It's a good practice to catch specific exceptions so you're not randomly missing some crucial bug in your application. Sometimes you want to catch a small exception, but let others bubble up. As-is, you'd have to create multiple catch blocks to catch each individual exception or add code to check to see if an exception is of a certain type to decide whether or not to rethrow it. Doing a bunch of casting checks will be a performance problem -- granted, maybe not a huge one, but moreso than separate catch blocks, I believe (I haven't tested that theory).
Let me give you an example. Let's say you have a string value you need to convert to an integer and then use that as an array index. If the value can't be parsed, the conversion could throw three exceptions: ArgumentException, OverflowException, or FormatException. However, if you're directly feeding this into an array, you may end up with a good integer, but a bad index, which would result in an IndexOutOfBoundsException exception. With this, you may want the out of bounds exception bubbled, but handle the case of a bad number. Simply catching an Exception will obviously catch all situations. Instead, I'd like to see something like this: catch(ArgumentException, OverflowException, FormatException). Obviously, if you want to do something with the exceptions, you'd have to specify variable names for them, but you get the idea.
Again, this may not be a big deal, but I like the practice of catching all exceptions and dealing with them where they occur. I also admit that this may be a bad example -- anyone wanting to cover all bases would check the index, too. I'm simply noting one small example, tho. I'm sure I could come up with several others where developers make typical assumptions without catching the exceptions. Probably the most typical one is the NullReferenceException. Yeah, I caught you on that one, didn't I?