Partly because you're oversimplifying (OOP doesn't just exist to solve _that_), and partly because sometimes you just find some tools to intuitively feel better than other tools for a job. I'm not saying you shouldn't find out what problems something tries to solve -- I do some tutoring to help my classmates (and some freshmen) improve their grades, and one of the things I stress is precisely that which you described, I always present them a new concept as the solution to a problem; I think that's the way to go. What I'm saying, however, is that it isn't always the case that we need to know the problem _before_ we learn the solution. It's not like OOP is "just" a solution to that, so you might be using it to solve your own set of other problems -- and if it feels like the right tool to you (even if it isn't), you don't need to know why it originally existed.
I have to correct myself. I said "It might, in most cases", where I meant "it might, in some cases".
Did you learn assembly, out of curiosity? By the way, I'm also developing a love/hate relationship with Haskell.
As to college, in this matter it isn't very different to any other person learning how to program. They make the same mistakes..it just helped me better understand the kinds of problems my classmates have.