This is my impression, too. When I was TAing an intro CS course back in university, I saw students new to programming struggling with Lisp (specifically Scheme in this case) much earlier in the learning process than even C.
This manifested in a few spots. The first is, yes, s-expressions. Yes, yes, I know, s-expressions are integral to the power of lisp, and they're really not hard to read once you get used to them. All of that is beside the point. The reality I saw on the ground, when teaching people to program, is that even people who have no prior programming experience whatsoever, and therefore no preconceptions to get over, have a harder time grasping s-expressions than they do algol-style syntax. I don't know why. I didn't have the same problem myself. But it's a real phenomenon that I struggled to help people through on a regular basis, and the lisp community's defensiveness about it is not going to make it go away.
Arbitrary-seeming names with zero mnemonic value is another problem. Car, cdr, progn, etc. - it takes a special kind of personality to not be put off by this sort of stuff. Not everyone has that kind of personality. Not everyone should have that kind of personality.
Finally, all the hair-splitty (at least to a newcomer) distinctions to contend with. =, eq, eql, equal, and equalp, or let, let* and letrec. Sure, there are reasons for these distinctions. But a language that can get by without quite so many of them is going to be a lot more attractive to newcomers. Even if it comes at the cost of footguns, if they're unlikey to be discovered until later.
Another factor, I think, is that a heck of a lot of people don't think they will still be doing this for a long time.
Programming is something interesting and fun they are going to do for a few years while young, until (pick one) {their band takes off, someone funds their startup idea and they hire others to do the programming while they generate genius ideas and run the business, they get promoted to a high paying executive position that involved management and architecture and others do the coding, their podcast becomes a hit and they can live off that, the small company they work at IPOs or gets bought and they make enough to retire at 30, etc).
So they learn a fairly easy language that has lots of libraries that cover most things you do in a routine developer job.
...and before they know it they are 50-60 and still writing a lot of code, and realizing that if they had known they would still be doing this 30-40 years later they would have been better off if they had learned and used and gotten good with some of the languages that have a reputation of being very productive but hard to learn.
I'd also add spreadsheets and database to that. At one point I was the database guy at work, because no one else was available. I learned enough SQL to get by, but was in no way a database expert. Heck, we had to pick job titles at one point that described what we did to have on the business cards the company was giving us, and I put down "Database Roustabout" [1], which should give you an idea of where I stood. That was 20 years and I'm still the database guy at work. It would have been a lot better if sometime early on I had said "I'm going to become really good at SQL even though I'm sure someone else will become database guy in a year or so".
[1] Roustabout. NOUN. An unskilled or casual laborer. (North American) A circus laborer.
