Q:

Why are there no best cases in Big O notation for Array/Stack/Queue and other data structures?

I was going through this cheat sheet https://www.packtpub.com/sites/default/files/downloads/4874OS_Appendix_Big_O_Cheat_Sheet.pdf and I am wondering why there are no best cases mentioned on the website. Why only average and worst cases ? 

A:

Mostly for the same reason you buy car insurance or medical insurance but don't buy winning the lottery insurance or I was healthy insurance: there is value in protecting against the unusual (or malicious) large downside outlier event, but there is no need to "protect" against similar upside occurrences.
The secondary reason is that unlike the worst-case guarantee that no input will trigger the behavior, the "best-case" guarantee isn't very useful without further characterization of exactly what inputs trigger the best case. Many algorithm implementations do include such information as part of additional fine-grained performance guarantees, but that lies mostly outside classic complexity analysis.
Downside Insurance
This part assumes that the usefulness of the "expected" complexity is obvious - it is the performance you should expect if your input matches the distribution assumed in the average-case complexity analysis. This naturally raises the question of why include the (unlikely) worst-case analysis without including the superficially symmetric best-case analysis.
In general the best cases certainly are calculable1 and they tend to cluster around two values: O(1) (e.g., for most structure operations) or O(n) (for algorithms that at least need to examine all their input, and if they have a special case to detect that the input is already in the desired format), and so the best case just doesn't really matter. Often algorithms will not even have special handling for the best-case scenario and the average and best-case complexity is identical.
Basically, when selecting an algorithm, you should expect the average case, on average. Then you have to look at the outliers: what happens in the worst case, and in the best case?
The worst case is really important because if your usually have n*lg(n) behavior but occasionally have n! or 2^n or even n^5 behavior, it might take down your application, make your service unavailable, etc. So the worst case is worth considering, both for inputs that may inadvertently trigger it, and to account for malicious use that may trigger it on purpose. 
In the best case, you have some behavior which is either tied or better than the average case. That doesn't really matter. You are already designing for a system where the usual result is the average case, so if you have some really weird input that happens to trigger the best case, that's cool - but it isn't a core criterion that you'd use to select the system, because it's an outlier.
Characterizing Best Case Inputs
Now, you might argue that your particular input is going to trigger the best case all the time, so that the best-case complexity is important. The problem is, the best case complexity alone isn't enough to guarantee anything. It's is only telling you that for at least one input, this is the complexity and doesn't tell you what that class of inputs are. You have to know the details of the specific algorithm to figure it out. You can easily make the wrong assumptions: for example, if a sort algorithm has an O(n) best-case complexity, you might it assume it is for already sorted inputs, right? In fact, it might be for "dense inputs" where it uses radix sorts, but then falls back to merge/quick/whatever sort for sparse or non-numeric input. 
Once you accept that the "best case" alone isn't enough, you are left with characterizing the performance of the algorithm for your specific input. That turns it back into an average case analysis for some particular input distribution (all average case analyses need to have some assumed input distribution and "uniformly random" is typical). At this point, you might as well dispense with O-notation entirely and just characterize the actual runtimes on the platform of interest.
Worst-case complexity on the other hand doesn't have this issue - it guarantees you that that there doesn't exist any input that triggers worst case behavior. That guarantee is very useful. The best-guarantee that there exists at least one input that the algorithm is very fast doesn't help much.
Finally, if published best-case was ever really an important selection criteria, most algorithms could trivially encode a single known input into the algorithm which returns a known output, with minimal loss in performance (on the other hand, detecting a generally useful set of special cases for good performance often slows down the non best-case uses).
It is mostly about what's interesting...
To be fair, you often do find the best-case complexities listed, probably simply out of a desire for symmetry or because it is easy to do so. Wikipedia certainly lists best-cases for sorting algorithms along with the other cases. So it isn't like they don't exist (as you imply in your title) just because you found a .pdf that doesn't list them, but mostly that they are aren't interesting.

1 In many cases they are much easier to calculate, often trivially, than the average case (which is often the most difficult) or the worst case. That's another reason you don't see the best-case complexity listed: it is often obvious by inspection. You could consider that a third reason that best case complexity isn't interesting.

