Even if so, a compiler can read your Lisp code and find errors that are run-time problems in Forth.

  $ cat errors.tl
  (defun bad ()
    (length (cons 3) x))
  $ txr -e '(compile-file "errors")'
  errors.tl:2: warning: length: too many arguments: max 1, given 2
  errors.tl:2: warning: cons: too few arguments: needs 2, given 1
  errors.tl:2: warning: cons: constant expression (cons 3) throws
  errors.tl:2: warning: cons: constant expression (cons 3) throws
  errors.tl:2: warning: unbound variable x

and this is meeting a fairly low bar; we're not even looking at type checking.

In Lisp I can work in a ahead-of-time compilation model just like C, Pascal or Java where I build the source files to object files, and the editor takes me to places that trigger diagnostics like the above.

What matters in readability is is how easily someone versed in that language can spot the error in bad code, and convince him or herself that good code is good, taking into account and advantage all the available tooling.

Forth is implementable in a tiny amount of space, and can produce fast executions. It can be fast when interpreted, and supports a straightforward compilation model. These are worthwhile qualities. Every computer scientist should know about Forth.

Without a doubt, Forth could compile a file and be able to warn that there is a stack underflow. (E.g. by taking advantage of the stack effect annotations, and check them against the actual effect, based on knowing the semantics of words). It won't be able to pinpoint it very precisely though. Without annotations, it is not easy to determine. A defined word which consumes 17 operands from the stack, and produces 9 in their place can be perfectly correct.