If you go through A Gentle Introduction to Haskell[0] I think you'll see it's a pretty simple language. There aren't that many parts of core Haskell to learn about.
Perhaps the abstractions such as Monad and Functor are more complex, but they don't seem anymore complex than some of the design patterns used to accomplish what they're used for.
Now, true, the syntax is much more complicated than Scheme. You can operators and precedence and all that. But while definitely complex, it is mostly consistent with math notation. I tried to teach with Scheme first (following www.bootstrapworld.org) before I created this, and I found the change in syntax from what they are used to can be a real obstacle for children. This is also consistent with the comment about MIT moving to Python, which similarly has much more complex but familiar syntax.
'All members of this [ALGOL] family are made from more or less the same material and for the same kind of programmers - those who love the machine more than the problem.'
Contrast with Lisp: 'a language that would help programmers solve problems without forcing them to think about the elements of a machine.'
So it really depends on one's interpretation of 'Computer Science', and the choice of what to prioritize from the subject: engineering or ideas.
But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere':
'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings, rotations, and congruences. A fractal set generally contains infinitely many points whose organization is so complicated that it is not possible to describe the set by specifying directly where each point in it lies. Instead, the set may be defined by "the relations between the pieces." It is rather like describing the solar system by quoting the law of gravitation and stating the initial conditions. Everything follows from that. It appears always to be better to describe in terms of relationships.'
So, rather than condescending, I find this interesting: these are two dissimilar approaches to solving problems.
Your comment about baking an apple pie 'without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients' was also an excellent statement of the differences between these points of view.
Barnsley's perspective was that relationships may indeed be a better way to describe structures. His concern was fractals, but perhaps the analogy extends to the logical structures that comprise a program.
You can claim that it's interesting that there are these two approaches, but the quotation you gave was definitely condescending, because it flatly states that one approach is better than the other, despite the widespread success of the latter. The argument that it's good to abstract as much as possible from the machine is interesting, but to me it is by no means obvious.
I don't really see the relation with fractals. Although it is an interesting quotation, the relation of fractals to real world phenomena is often very dubious.
All functional languages can express a sequence of steps. More yet, on most of them you can later decide to transform the sequence, instead of just generating code from it.