Most definitely, some of the stuff you're studying you'll never use. But a career in software engineering takes a LOT of twists and turns, ups and downs. Technologies and techniques come in and out of vogue. But one thing remains solid throughout: Algorithms. Without a solid understanding of algorithms, you'll never be able to write efficient software. And what's worse, you'll never even know why. You'll lack the tools to even be able to question why, until you study the algorithms written by the giants of computer science. They've done the hard work for you. All you need to do is learn the how and why.
But it doesn't stop there. You also need to have a solid understanding of at least one level below where you're working at (and preferably many levels). I'll relate a small example:
When I was working at a bank, all of our software was written in high level languages (mostly COBOL, Java, Python, and PERL). You'd figure that there's no need to understand CPU architecture, right? WRONG.
We started getting reports that our web app (for funds transfers) was crashing (not the regular Java crash, where the app keeps going; the hard crash where the entire web app goes down and has to be restarted).
Needless to say this was costing us a lot of money in lost business. All we had was a Java crash report with a stack trace that went into a JNI call. At this point, it's outside of Java, so the trail ran cold. Or did it?
One nice thing about Java crash reports is that they include a memory dump of the stack area, as well as a dump of the CPU registers. I know software and hardware top-to-bottom, from transistors to logic gates, to CPUs & machine language, through the BIOS, kernel, OS, libraries, all the way to the application level. It wasn't that difficult to trace back through the stack in the memory dump, disassemble the shared library that JNI was calling (a library for secure thumbprint recognition), and use the stack offsets to track execution right up to the memcpy() call that was being passed a NULL pointer (the thumbprint recognizer code returned NULL if the scan was incomplete, and the the library wasn't sanity checking the result before making a copy of the scan buffer). I was able to turn the library vendor's story around from "It's a problem on your side" to "We'll have a fix out for you in a couple of days".
I was the ONLY person in the company capable of doing this, simply because I paid attention in college. The knowledge I leveraged to fix the problem was seen as pure magic by other engineers because they didn't understand the theory and lacked even a way to ask the right questions, let alone answer them. Finding the answer is easy; It's finding the question that's hard.
So yeah, you can skip college and live a life of mediocrity. It pays pretty good, too. But you'll always be on the bottom rung. You'll be the guy who gets work in good times, and then gets laid off in bad times. When the market's hot (like it is now), companies tend to get driven to desperation, taking any programmer with a pulse. And then the bubble bursts, leaving all these now-jobless mediocre programmers asking "Why me?" when it's really their own fault.
If you're serious about programming, you'll take the time to learn. The best programmers never stop learning new things, and never stop reading new books. College is merely the beginning of learning & knowledge.