As someone who has lived through a big chunk of the 'computer science' lifecycle arc :-) My perspective is a bit different here.
"Programming", or the skill of writing specifications that can be translated via software into product has come a long way from the 60's to the present day. People I meet, interview, and work with, often fall into three broad chunks of the spectrum.
At one end there are 'coders', who are essentially cooks, they take previously written code, adapt it to their requirements, attach it to third party libraries and ship the end result. They have been essential to the boom in Internet companies for decades because they ship a lot of code and they are relatively inexpensive (with respect to the expected generated revenue) to hire. When their code doesn't work as they expect they generally iterate on it using other suggested solutions until they arrive at one that operates the way they need/want it to.
In the middle are 'engineers' who build more at the system level and can fill in the gaps with third party software when needed but are also fully capable of generating the required capability starting with a blank screen. When the system doesn't work they expect they can analyze it from first principles to get to the root cause of the problem.
At the other end are 'scientists' who think about the problems of the nature of computing. These folks rewrite an algorithm in three different ways to understand how different compute architectures might execute it. Driven by the joy of discovering new insights about how computers work, if something they build doesn't work they are delighted because it has illuminated a gap in their understanding that can be productively filled.
Different educational settings are useful for addressing the goals of the student, and in my experience those goals will be different depending on where on the spectrum of 'programmer' they see themselves.