When this kind of switch was happening in CS departments, as a graduate student I was part of a "movement" that advocated for switching away from things like Scheme to Python for introductory classes in my elite CS institution. (We focused on other things as well such as more interdisciplinary research, which was where I was more passionate, but that's a separate matter.)
My reasoning at the time in this order was:
1. Widely used tools and practices offer a flywheel of usefulness that can help motivate undergrads to learn about computation. Once you learn Scheme, well now you've learned Scheme. But at the time if you had learned Python you could then use something like Python's system and socket APIs to play around with the lab or personal Linux systems. On the web side, there was web.py or Flask (haha this was the late 2000s/early 2010s) to motivate yourself to keep going. The student could spend their summer building apps and tools so that they appreciate computation for more than just its "aesthetic" beauty.
This was a time when CS wasn't all that prestigious on its own and salaries weren't as high as they are now, so many folks who banged their head against Scheme or MMIX or LC3 would just churn to the EE or MechE departments.
2. As a grad student it was almost trivial to set an exam paper that could weed out most of the class. This was especially trivial at the introductory class level where Scheme would be taught. If the concern was rigor it was very simple to maintain the rigor in other ways.
3. For better or for worse many undergrads had no intent of going to grad school, and many of the undergrads taking our classes weren't even students of computer science. They were electrical engineers or industrial engineers who wanted to learn enough programming to automate things in their field but were more interested in their actual areas of concentration.
In the years since my thinking around this evolved, but I still share the same conviction I did then. Probably moreso given the sheer ubiquity of Python now.