I hear and appreciate what you are saying about evidence. First, I'll give the usual disclaimer that evidence is hard to come by in CS Education because it's hard to collect properly. Second, I'll point out that I have been involved way more heavily in a completely different sub-branch of CS Education; if you would like to hear evidence for, say, the value of data science as an introductory computing context for non-majors (CS0), then I am very happy to share what I know that is backed up by evidence. Only recently have I started getting involved in actual CS1 research in a deep way - so I can't really take much responsibility for the lack of research. I mean, I've only been a professor for two years now :)
I don't know if you were hoping that I'd be able to find evidence in other papers or generate the evidence myself. For the former, know that I tried hard to do a proper lit review on this (and I'm not even going to get a publication out of it!). I even asked some Racket people: one basically repeated Matthias Fellisen's disgusting opinion that CS Ed research is not possible, and the other just pointed to one of their papers citing theoretical arguments. At some point, I'm hoping to ask Kathi Fisler if she has a better set of citations, assuming she'll still talk to me if she finds this document :)
As for whether I should be responsible for conducting research to disprove HtDP, I have considered it. I might even do it. Certainly, I am trying to experiment with several methods that can hopefully provide contrasting information. For instance, I want to see if I can replicate the Rainfall success by teaching more explicit functional decomposition and pattern application in my CS1. Of course, I'm also trying to do a ton of other projects, and my job promotion is based on my teaching, not my research.
Part of my issue is that I should not be responsible for proving that their ideas work. They thought up a bunch of arguments, and then claimed that This Is the One True Way to Teach. If I made the claim that teaching works better when I punch students at random intervals, and you disagreed, you wouldn't feel that the burden of proof was on your end, right? I should need to prove my Punching Method, to some extent - perhaps at least some pilot studies? The Racket folks made up a lot of claims, and then didn't really prove what they said. That was over 10 years ago! I've been busy getting my doctorate, what is their excuse?
Separately, you provide some very valid hypotheses for why my students didn't resonate with Racket. In general, I think you have some good points about SWE vs. CS, but I have a different perspective. There's some mental model here, common in certain communities, that learning happens in a very direct way - if you just arrange concepts in the right way, things will click. I think that learning is a lot more messy and chaotic and driven by a lot of human issues and tough to work with. Transfer is hard. You can't teach CS divorced from programming and this messiness, it's just not realistic. Perhaps a small percentage of my students who are destined to be brilliant Theoretical Computer Scientists and professors will find all the learning to be orderly. But CS is a broad umbrella nowadays, and motivations are complex. I'm not really doing my points justice here, but read some of what Andy Ko and Mark Guzdial have been writing about - I think they're more my kind of CS Education folks :)
Finally, I feel like I should at least address your hypotheses: (a) Yes, my students want industry-relevant languages. They all said this to me explicitly, once or twice during class :) I really tried my damndest to give them a good justification for why Racket is a good intro language. I really tried to sell it. I failed - either the arguments weren't delivered well, or they weren't received well. I will point out that some students told me last spring that they earnestly thought I was in favor of Racket for CS1, so anecdotal evidence that I at least tried! (b) Yes, most other faculty don't know why this is being taught this way, and they don't conform their courses to the vision. Should they? What's wrong with their courses that they need to be "Racketified"? What would fixing my junior-level Algorithms course to be more Rackety? Perhaps the Racket folks should offer some explanations. Or, here's an alternative - the PbD curriculum is not solving general purpose problems, and the approaches they teach are not generalizable to other parts of the curriculum. All CS1 courses are full of useful lies - the PbD curriculum's shouldn't be propogated downstream, they should just be tossed out in favor of lies that at least align with the next courses'. (c) I taught the Design Recipe and pretended it was effective. I told my TAs to grade on it, same as the other instructors have done in previous semesters (reusing rubrics helps a lot). Perhaps I'm not a good actor, but I really tried my best to sell it. Maybe my TAs weren't good, but I doubt that. They were all excellent students who excelled at the course when they took it. If they're not good at it, well I don't think we'd have been able to get better ones, so you have to take that as a limitation of the system.
I understand why you are disappointed by my article. I am disappointed in the entire HtDP community. I think that this is a bad situation, and I'm not clear that I can make it better by writing an article. However, my goal wasn't to persuade you that Python was better than Racket for CS1. It's to make the points that right now, in my context, I should be teaching Python instead of Racket. Also that the HtDP community should be ashamed of the awful job they've done proving their points, and they should stop being so mean to everyone.