I think that for most people, s-expressions are harder to deal with than curly braces and begin/end.

1. Non-Lisp languages have fewer braces in general due to the presence of non-expression "statements" and infix operators, while in Lisp nearly everything is an s-expression. Common Lisp in particular has a lot of double parens, so even a garden-variety LET form already has _three_ levels of parens, or four when you have a function call involved:

(let ((x (foo :a 1 :b 2)))
(princ x))

2. Indentation and spacing conventions in non-Lisp languages generally make it easier to spot unbalanced braces, while Lisp indentation and spacing conventions are specifically designed to make the braces "disappear".

3. Non-Lisp languages have a wider variety of delimiters, which can help visually distinguish groups of delimiters in . Common Lisp and Scheme almost exlusively use parens (). Clojure has more variety in this area, and I have no doubt that this was a deliberate design distinction.

4. Lisp and Scheme tend to be more functional, and discourage things like early returns, often leading to deeper nesting in the syntax tree and therefore a larger number of parens to juggle. Many other popular functional languages generally use as few parens as possible, almost entirely eschewing their traditional purpose for function calls, so they don't share this problem.

The combined effect of these differences makes editing non-trivial Lisp code a bit tiring and slow/difficult for someone who isn't already very comfortable doing it without the editor support. That's a serious deterrent for would-be newbies, who could go try any one of 1000 other interesting good-quality languages out there.

Being forced to use _Emacs or Vim/Neovim_ of all things is a huge compounding factor. At that point, they'd be better off even with Clojure, which at least has excellent support in VSCode (via Calva https://marketplace.visualstudio.com/items?itemName=betterth...).

C-like curly brace pseudocode:

function pythag2(a, b) {
if (a <= 0 || b <= 0) {
throw MathDomainException("Sides of a right triangle must be positive in length.")
}
const aSquared = pow(a, 2)
const bSquared = pow(b, 2)
return sqrt(aSquared + bSquared)
}

Algol/Pascal-like begin/end pseudocode:

function pythag2(a, b)
if a <= 0 or b <= 0 do
raise MathDomainException.new("Sides of a right triangle must be positive in length.")
end
const aSquared = pow(a, 2)
const bSquared = pow(b, 2)
return sqrt(aSquared + bSquared)
end

Haskell/ML-like pseudocode:

square = pow 2

pythag2 a b =
if a <= 0 || b <= 0
then (MkMathDomainError "Sides of a right triangle must be positive in length.")
else
let aSquared = square x
bSquared = square x
in sqrt (aSquared + bSquared)

Lisp-like pseudocode:

(defun pythag2 (a b)
(if (or (<= a 0) (<= b 0))
(error 'math-domain-error
:message "Sides of a right triangle must be positive in length.")
(let ((a-squared (pow 2 x))
(b-squared (pow 2 x)))
(sqrt (+ a-squared b-squared)))))

When writing this, the _only_ one that I had to stop and really think about was the Lisp one. With Parinfer, the parentheses completely disappear and I can code at the speed of thought, and I have the sublime Lisp experience that everyone talks about. But without it, I had to somewhat-carefully construct the "skeleton" of the IF and LET forms, and I had to literally count the parens at the end to make sure I did it right.

Moreover, I would bet good money that for most inexperienced programmers, the Lisp version would be the hardest to read.