TypeError also should be more specific because it can occur for a multitude of reasons; along with stuff like AttributeError, it's one of those exceptions that could arise from multiple causes on a single line of code, none of them obvious. For the specific case of passing the wrong number of arguments, that's usually a result of programmer error, not input errors to a valid program, so it's not a case worth optimizing. For control flow uses of TypeError (e.g. using duck typing to choose code paths), performance loss is a valid point.

ImportError requires disambiguation for similar reasons (since a single import statement could error because the target module is missing, or because one of its dependencies fails to import; you need to be able to tell the difference, and a line number doesn't help). Beyond that, there is little cost to making fully detailed ImportErrors; if you're risking ImportErrors in your program's hot paths, something is wrong with your design.

As for needing a use case: Every feature starts at minus 100 points (ref: http://blogs.msdn.com/b/ericgu/archive/2004/01/12/57985.aspx ). There is a limited amount of development and testing resources, more code means more opportunity for errors and increased disk and memory usage, etc.

I agree that KeyError is a relevant comparison, though you'd be surprised how much cheaper indexing a sequence is relative to dictionary access; hashing and collision chaining are usually tripling or quadrupling the work relative to a simple integer lookup in a sequence. The more expensive the non-exceptional operation, the less you need to worry about the expense of the exceptional case, simply because the code was never going to run that quickly anyway.