Software engineering (like topics above the red line) is not computer science (like topics below the red line) and it will never be. Chuck Connell explains this with a nice analogy:
Would a good structural engineer necessarily be good at designing the buildings he or she is analyzing? Not at all. He might be lousy at talking to clients, unable to design spaces that people like to inhabit, dull at imagining solutions to new problems, and boring aesthetically. Structural engineering is useful to physical architects, but is not enough for good design. Successful architecture includes creativity, vision, multi-disciplinary thinking, and humanity.
This observation frees software engineering researchers to spend time on what does succeed — building up a body of collected wisdom for future practitioners.
Gerald Jay Sussman when asked why he teaches Python at MIT and not Scheme anymore, he gave the following answer:
In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme — it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.
And why Python, then? Well, it probably just had a library already implemented for the robotics interface, that was all.