...

Show me someone who claims to understand the first piece of code and not the second (once you explain that foo(bar) becomes (foo bar)) and I'll show you a liar:

1: if (foo) { bar(arg1,arg2) } else { baz(arg1,arg2) }

2: {if foo (bar arg1 arg2) ;else (baz arg1 arg2) }

It isn't a radical step to move that last bracket to the end of the previous line, and if you really don't want to, then you're free to leave it where it is as long as you don't plan to share the code with other LISP programmers. The fact that you can write bad Scheme code whether intentionally or through not knowing much about it doesn't change this fact. Here's your above code written with decent style. If you don't like the letrec syntax, you can just define it as a separate function, which may make it more readable for those who aren't used to it.

(define (isort l)
  (letrec ((insert
                (lambda (x ls)
                  (cond ((null? ls) (list x))
                           ((<= x (car ls)) (cons x ls))
                           (else (cons (car ls) (insert x (cdr ls)))))))
    (foldr (lambda (x y) (insert x y)) nil l)))

If you still can't read this, the problem is most likely that you're trying to count parens. The only time a LISP programmer should need to be counting parens is when making sure they put enough trailing parens somewhere (and your text editor ought to do paren matching which trivializes this): the rest of the time indentation tells you what scope you're in. If your argument is that poorly indented/written code is harder to read, then that's a revolutionary and insightful statement no matter which language you apply it to.