As computational science and engineering becomes more common, it becomes important to ask what should all scientists and engineers know about computer science to be effective.
To me, the Triple Whammy seems more like why computation is interesting philosophically, but it's not what engineers and scientists need to know.
I see engineers and scientists go astray when they develop -- or request the development of -- some computational solution all the time. They start wrong and then, when they get in trouble, they don't know how to recover. They start wrong because they don't know about modular (de)composition, i.e., attacking problems from the outside in. When they hit serious performance barriers, they try changing languages and other hacks, because they don't know about algorithmic analysis and design.
The value of algorithmic design is easy to motivate via examples. The value of modular (de)composition is more challenging to make stick, despite the many decades that have passed Abelson and Sussman first brought those ideas to engineers.
I believe what people don't see is that Computer Science is that part 'upto' the programming. Making sure that the algorithms you will be using are appropriate, that the tables you're using are normalised, ensuring that your design doesn't need to be reworked when a new module is to be included, etc.
The worrying trend I see is that many computer engineering graduates are interested in only learning a large set of programming languages but dislike courses like algorithm design, not realising that these languages are merely tools for implementing solutions. The end result is what you could call technicians but not engineers.
I think students are interested in learning languages because employers at interviews ask, "Do you know the X language?" That's especially true for entry-level, non-PhD candidates.