Some of these objections are the author taking well-known properties of CL as must-haves, and evaluating other languages against them.
Considering them must-haves is perfectly reasonable for a programmer who wants to work in that style. For example, being able to (put roughly) modify any part of the system at any time, and let the semantics decide what happens.
Scheme/Racket absolutely is not CL, and Racket has been moving further away from CL than Scheme already was. I've worked on critical production systems in both Scheme/Racket and CL professionally, and they are very different languages, and people wouldn't confuse them if they didn't both use S-exp syntax. (Individual Lisp family developers are also different. There are some shared memes, but you don't end a Lisp family language expert today, and shunning that $500K Python job, without being stubbornly self-motivated and/or self-destructive.)
One of the keys to learning Scheme originally was to put aside my biases about what was important, try to use and then understand the idiomatic way, so that you can then decide what makes sense.
(Examples: My own first bias when learning Scheme was trying to micro-optimize for runtime as I coded, like I would in C, but I didn't know what cost model I should reason about. If you look at the first Scheme code I wrote, https://pkgs.racket-lang.org/package/html-parsing , it's a little like a C programmer with some non-Scheme Lisp experience.) One of the next barriers was learning to avoid mutations and premature exits, and to leverage tail recursion. Before I learned that, I couldn't have told you that can make code easier to read.)
When we were first learning computer things, there was an implicit suspension of disbelief or acknowledgement of not knowing. As we grow more knowledgeable, we have to be careful not to plateau or become rigid, assuming we know the right way, and dismissing things that are nonintuitive. Sometimes we will be right to dismiss them (and often will be, in corners of "tech"), but sometimes we will miss out. It's even not necessarily a net loss if we invest in understanding a perspective, and then determine its flaws, because we may still have added some new useful ideas to our mental toolkit.
This analysis is spot on. The author is annoyed about the absence of many things that, in most programming languages, would be seen as outright absurd. People have come to realize multi-methods, monkey-patching, and mutable interfaces break down when writing code at scale, across a large team. It's no surprise that Racket has internalized these lessons, and someone in love with Common Lisp would see these as shortcomings. A Haskell programmer could similarly rant about Python's lack of closures, a C++ programmer about JavaScript's lack of templates, and so on. There are many reasons to hate many languages, but "that language isn't this language" is a rather petty one.
Er, I rather meant that Python doesn't have a first-class lambda definitional form. You are right that you can get the python runtime to make closures.
Considering them must-haves is perfectly reasonable for a programmer who wants to work in that style. For example, being able to (put roughly) modify any part of the system at any time, and let the semantics decide what happens.
Scheme/Racket absolutely is not CL, and Racket has been moving further away from CL than Scheme already was. I've worked on critical production systems in both Scheme/Racket and CL professionally, and they are very different languages, and people wouldn't confuse them if they didn't both use S-exp syntax. (Individual Lisp family developers are also different. There are some shared memes, but you don't end a Lisp family language expert today, and shunning that $500K Python job, without being stubbornly self-motivated and/or self-destructive.)
One of the keys to learning Scheme originally was to put aside my biases about what was important, try to use and then understand the idiomatic way, so that you can then decide what makes sense.
(Examples: My own first bias when learning Scheme was trying to micro-optimize for runtime as I coded, like I would in C, but I didn't know what cost model I should reason about. If you look at the first Scheme code I wrote, https://pkgs.racket-lang.org/package/html-parsing , it's a little like a C programmer with some non-Scheme Lisp experience.) One of the next barriers was learning to avoid mutations and premature exits, and to leverage tail recursion. Before I learned that, I couldn't have told you that can make code easier to read.)
When we were first learning computer things, there was an implicit suspension of disbelief or acknowledgement of not knowing. As we grow more knowledgeable, we have to be careful not to plateau or become rigid, assuming we know the right way, and dismissing things that are nonintuitive. Sometimes we will be right to dismiss them (and often will be, in corners of "tech"), but sometimes we will miss out. It's even not necessarily a net loss if we invest in understanding a perspective, and then determine its flaws, because we may still have added some new useful ideas to our mental toolkit.