It's also important to teach students how not to prematurely optimize, how to find places to optimize, how to use abstraction, and a lot of other things that just are kind of shown and glossed over.
Except if you need a certain level of performance. It would be silly to write a million lines of code to find out that you could never reach the level of performance that was actually required.
But in general you are right.
I'd like to add that perhaps the most difficult aspect of software engineering is a situation in which specs change all the time. This happens a lot during prototyping, and afterwards, when a prototype has been promoted to a product.
When people use that phrase, they're usually talking about the nit-picking, obfuscation-inducing stuff that'll get you a 3% increase in speed, that you'd generally do at the end of the development cycle.
We also all understand the limits of our hardware and our abstractions we are applying to the project at hand. If we should be considered professionals we need to prove it by being able to reason about our systems. We should be able to tell beforehand what abstraction is appropriate for the project. That is the knowladge that must be taught.
Because you need a long-living project, and such projects are (a) expensive and (b) rare if you mean them to be thrown away. University is not predisposed to carry those out, thus it's industry's job to teach programmers how to do that. Universities are well-suited for teaching different things, which are very difficult to pick up working in industry alone.