Because average case requires a definition of "average". Specifically, average over what distribution of inputs?
Worst-case does at least give you an objective guarantee: whatever input you consider, it won't be worse than this. That sort of guarantee still has some value even if the worst-case inputs aren't representative of what you're going to be doing.
On the other hand, average-case doesn't necessarily correspond to anything very much. Suppose you just take the uniform distribution over inputs of a given length. Why would you feel that the mean number of steps the algorithm takes is a useful measure of anything? Probably your inputs don't look much like a uniform distribution. The mean based on any distribution doesn't give you any guarantees about actual performance on specific instances.
Also, and this might, sadly, be the real reason, average-case complexity is hard. It means you have to understand how the algorithm behaves on essentially all possible inputs, and getting good bounds for all kinds of input is a lot of work.
One place where average-case is used is amortized analysis. Consider a dynamically sized hash table where, if the table is more than, say, three-quarters full, you copy everything into a new table that's double the size. In this situation, inserting an element into a table of size $n$ can take up to $2n$ steps, which is horrible in the worst case. However, you only need to do this expensive copying operation once every $3n/4$ steps. On average, then, each insert operation causes $2n/(3n/4)=8/3$ amount of the work needed to double the size of the hash table. So, in a very strong sense, the average cost of growing the table is just a constant amount per insertion, and this is completely independent of what insertions are done. This is practically very useful when analyzing algorithms that use hash tables.