How would you know when to use a hashmap and when to use a list if you don't know anything about big-O notation?
Let's say you want a data structure that performs three operations. Insert, Delete, and Find (as in, 'is this in the database?'). The intuitive sense may come from saying, "Linked-Lists would be horrible for this! Each operation would be slow." (O(n)) The practiced programmer may say, "I can keep the data sorted and use an Array. Those would probably be faster." (O(lg n)) However, if you learned a little more CS and how hashes work, you would know that they are constant time for all three operations. You never had to waste time thinking about which choice to make because you know how hashes are implemented and that they specialize on those operations running in constant time.
Besides, big-O notation takes no time at all to learn. I learned it's theory as a freshman in high school during algebra II when we wanted to know which of two polynomials grew faster. Take the most significant part, rip off the constants, and that's its growth rate.
Well, it's an upper bound on its growth rate. And only after some possibly-gigantic n.
We also understood that it was as n -> infinity, hence why f(n) = 2x^4 would have a larger growth rate than g(n) = x^2 + 5000. When you're talking about scalability when programming, you're going to have to understand big-O, how constant factors come into play (why Floyd-Warshall at O(n^3) is often better in practice), and how big-\Theta works. If not, you're eventually going to make a mistake and slow everything down.