In the worst case, we would have to go through the whole list as the minimum value would be at the end of the list.
You have to go through the whole list in any case, because otherwise you do not know if the current minimum is indeed the absolute minimum. So the algorithm would always require n iterations.
The only exception is if you know bounds on the possible values, for example that the integers are all positive, and you have already found a 1 (then you can stop). That does not change the complexity discussion, though.
Expected time is just the average, expected, running time of the algorithm using the intended input.
Say you've got some few million user records and want to sort them, you might want to use an algorithm which is the most suitable for your input, and as such gives the best expected running time, as opposed to an algorithm which has better worst-case running time but worse expected running time.
Sometimes for example the constant factors for the time-complexity of an algorithm are so high that it makes sense to use algorithms with worse time-complexity but smaller constant factors, as it gives you better expected running time with small input, even though it would get horribly outperformed with bigger input.
Perhaps a better example would be the classic quicksort algorithm, which has worst-case running time of O(n²) but expected average running time of O(n log n), regardless of input. This is because the algorithm uses(or rather, may use, depending on the implementation) randomization. So it's a so-called randomized algorithm. It runs a bit differently with every invocation even with the same input. As such, thre's no universal worst-case input for the implementation, because the worst-case input depends on the way the algorithm chooses the pivot for dividing the given input. And as such, one can't just supply some pre-defined input causing the worst-case running time. This is often the case with randomized algorithms, which aim for better expected, average running time regardless of the input.
It's all about using the right algorithm for the input at hand.
Best Answer
They are applicable to all cases, but "worst case" is the one most programmers go by because it's just better to always assume the worst case (when designing algorithms).