I took a "Software Testing Theory" class in the 2nd year of Software Engineering, then every course after that we were using jUnit (or whatever) for unit testing, and writing Software Test Plans and executing them on everything we did.
It was great.
But the reasons for testing weren't really emphasised or even discussed.
(And a first-year course where we were required to use jUnit in the assignments, although again it was incidental and not at all a focus.)
The vast majority of students in my program honestly don't give a flying fuck about the academic opinion that CS shouldn't behave like a vocational school - the intent is to go into software development, and CS is the only offering that touches on it. Yes, we're all capable of learning various things on our own (including the theoretical aspects of CS, as instructors in these fields are typically so incredibly incompetent that students are required to teach themselves, anyway), but that's not a justification for providing an education that is largely irrelevant.
If I really wanted to study theory and computational mathematics... I would have studied computational mathematics.
Were it not for the perceived value of a CS degree, I suspect a substantial number of students wouldn't even bother, and probably flock to Coursera, etc.
And you're forgetting companies like Google, Amazon, etc. who expect candidates to know CS theory pretty thoroughly. What kind of school would be proud of grads who couldn't get into one of these top companies? Software engineering is also easier to pick up on the job than in school, and vice versa for the theory.
It's condescending to describe CS theory as "largely irrelevant", but this also sounds like a case of sour grapes. There are plenty of tech curriculums that are light on CS theory--try looking for "Informatics", "IT", "Information systems" and so on.
The vast majority of students in your program are unqualified to have an opinion. There's no point in having a university teach you version control systems if you're just going to end up learning it anyway. It's basically impossible to make students good software engineers (which has nothing to do with version control systems or other trivial things like that) in an academic setting. That's only something which comes with experience.
But that is the key phrase, "on the job". I know I personally didn't go to school to fit all these check boxes. It seems like a poor choice to me that you and your classmates would (1) enter into a CS program without much interest in CS, then (2) blame the field of study for not being interesting to you. I for one am glad I got a CS degree (for the CS degree's sake) and thankful for what I was exposed to in those years. These other check boxes? Sure they are valuable. That's what my first job was for.
Yes, well maybe they should get on with it then.
The beauty of CS is that the theory is directly applicable to the practice of software engineering. And because of this close connection between code and theory, you can develop significant coding skills just from doing the problem sets. As per the usual academic refrain, you get out of it what you put in.
If you think they should just be teaching you industry skills then you're wasting your time and money because college will never be as instructive as taking an internship in an actual company shipping code. Not only that, but you're paying for the privilege instead of being paid. Even if they rolled over and decided to go this route, academia does not have the knowledge or experience of what it takes to be successful in industry, must less impart that knowledge to you.
If you're going to go to college, take advantage of the academic strengths: the deep knowledge, the curiosity that goes beyond the immediate problem, the great minds you have at your daily disposal.
On the other hand, if your CS program sucks then it sucks and I'm sorry.
I'm currently trying to convince my organization to use version control, and because nobody has ever used it before, they just see it as a pain and more overhead that it's worth. To be perfectly honest, I felt exactly the same way before I was forced to use it for a 2nd year programming course.
Of course, since then, I refuse to not use it, even for my side projects where I'm the only contributor.
One of the big values of college is having a lot of other people around you learning the same things at the same time. This can be helpful when learning about subject matter and about tools like version control.
For instance, many programming exercises in various subjects taught at my university give the students a basic framework with missing functions, or a test harness, or some other piece of code that needs to be finished. These could have been shared via a version control system, and delivery could be made that way as well (using pull requests, branches, or some other feature).
That way, students would be encouraged to use version control while working on the exercises.
The way it actually is done here, though, is basically "learn version control yourself and justify your choice of version control system in your report" when doing group projects.