Racket was primarily designed for teaching and has been somewhat successful in that regard. I don't know of an empirical study, but if you attend a RacketCon or go to a Racket Summer School you will meet educators who talk about how Racket has positively affected their experience in education.
But maybe part of the issue is using Racket for what it's meant to be used for.
Racket is good for teaching computer science, which I'm contrasting with software engineering (often just called programming, although I don't like that). It seems like most CS programs at universities are really SWE programs in disguise. Of course, this is often what the students really want: a program to help them get jobs in industry.
Racket is good for building a slightly more mathematical framework of programming than a language like Python. The functional nature of the language promotes thinking about problems in terms of data and their relations, instead of in terms of procedures and state manipulation which tends to be how imperative languages are learned. (This is not to say that imperative languages can't be used well, or can't be used in a "mathematical" way, but this tends in general not to be the case.) If the end-goal is to teach students how to approach programming mathematically, then they are more likely to learn better with Racket than Python.
You will also have a problem now with students who have some prior CS knowledge disliking Racket because it doesn't aligned with their not-yet-fully-built notions of how programming languages work. The larger your classes, the more influence this factor will have. I think your survey ("Students do not like Racket") would be better if it were correlated with information like this. My gut feeling is that students with zero prior programming experience are likely to have a less extreme negative feeling of Racket than those who had previously learned a little Python, C, Java, Javascript, etc.
The issue of students not using Racket later in their degree is certainly problematic. Matthew Flatt (one of the principle authors of Racket) taught Utah's intro course in Racket just twice. When I asked him why it didn't continue, he more or less indicated that he had a hard time with it because it caused problems for students with the rest of the degree program. They learned stuff fine in his class, but the subsequent semester relied on knowledge of Java, and this was no good. Schools where Racket does well are schools where the various curricula are more cohesive in this regard, such as Northeastern and Indiana. (Speaking of which, Indiana should go on your list. I'm pretty sure their intro course is taught in Racket.)
You also claim that the Racket group have not published very much data, but you also are lacking the same data. For example, you say:
> Despite being ten years old, there is relatively little research to demonstrate the value of “Design Recipes” as a pedagogical approach, especially one that has long term benefits. One research study by the group indicates that students may be more prepared to apply principles of Functional Decomposition through this approach than students who do not, based on studies of the Rainfall Problem. Is this unique to using Racket? It’s a reasonable hypothesis, but not a proven fact.
but you don't provide evidence that it isn't the case, nor that Python is a better language for the same problem. I do believe there's value in expressing opinions without facts (or else I wouldn't be here!), but I think in this case your position would be significantly strengthened by having actual data to back up your claims.
I'd suggest that maybe your issue with teaching Racket was multi-fold: (a) your students wanted industry-relevant languages (SWE vs CS) and Racket is not that (which indicates either a need for industry-relevant languages or else an explicit explanation of why Racket is a good introductory language); (b) you lacked support from other faculty so students could continue to learn in the Racket environment past their first semester; (c) you don't appear to be a proponent of the whole "Design Recipe" thing, which is kind of essential to the intended Racket teaching methodology. I also wonder about other factors, such as whether your TAs were good at helping with Racket.
I want to make clear that I don't think you're wrong by necessity. It's entirely possible that Racket is actually bad for teaching computer science. But it's my opinion (as somebody who learned imperative languages first, Racket later) that your article does not really satisfy your claim, and I find that a little disappointing.
As an aside, I might suggest looking more specifically at what Shriram Krishanmurthi is up to. He's the most education-focused of the original Racket group, leading initiatives like Bootstrap to great success. He's also pretty active on Twitter, so if you're feeling up to it you might post your article there and tag him in. ;) (I think he's also on HN but I've forgotten his handle.)