Reading a short account of the rationale behind the change, described by Sussman himself, paints a very different picture:
http://cemerick.com/2009/03/24/why-mit-now-uses-python-inste... .
It's not that programming now "largely consists of debugging and customizing already existing code, often via frameworks". For one thing, it's only the narrow, web-constrained definition of "framework" that even vaguely works that way. Second, I'd argue that, unless the code which programmers debug has been written somewhere until the late 1990s, new code gets written often enough that programming largely consists of writing new code instead of debugging old one. That there are programmers hopelessly churning on the umpteenth bug because someone at the end of the Internet decided to change the format of their JSON objects and the mapping of their HTTP request handlers (pretentiously calling that "an API") is not a testament to how programming has evolved, it's merely a proof that not every change counts as evolution.
Instead, the choice of Python over Scheme -- which has been received with mixed feelings by almost every programmer able to write a Quicksort function without googling for compiler errors -- seems to have been driven by related, but vastly different reasons, such as:
* There are vast amounts of interactions spread over multiple languages, machines and platforms. Independently reasoning about objects, while essential to programming, is as central to teaching as integration in already existing architectures is. Unlike the early 1980s, when pretty much every new computer meant a new editor, a new set of programs and more often than not, a couple of new languages, being able to reason about existing architectures is incredibly important. Scheme is able to provide this, but requires fairly intimate knowledge of the implementation, whereas Python pretty much gives this away for free.
* A considerable deal of modern CS/CompEng research is centered around studying non-fundamental applications. It's important to have access to tools that allow people to whip up quick experiments. Whether Python does this better than Scheme is debatable, but Python does arguably score better in terms of integration and, therefore, in terms of being able to glue new fundamental discoveries to practical problems that they solve. Perl does that too, arguably better than Python, actually, but there are lines even seasoned teachers would rather not cross.
* Many of the so-called real problems come from more specific fields, are sloppier and can often be less rigorously stated than those for which SICP was initially written. Again, this is debatable, but Python is more universal and easier to convey. I don't know how much truth is behind this. I tend to disagree, because personal experience has shown me that this is the argument preferred by the kind of people who think that cool 3D data visualisation programs are a good example of a real-life problem and rotation matrices are a typical example of a useless problem that doesn't stem from real life applications.