(defclass person ()
   ((name :initarg :name)))

(let ((p (make-instance 'person :name "Pascal")))
   (eval (read))
   (setf (slot-value p 'address) "Brussels"))

There is no chance to see upfront whether this program will fail or not,
since the user can redefine the class person when (eval (read)) is
executed. At that time, the slot 'address could be added to the class
person. This is a contrived example, but similar things are indeed
actually quite useful in a certain class of programs. (Think of
frame-based knowledge representation systems, for example.)

On the other hand, in a statically typed language (with a sufficiently
interesting type system, like Hindley-Milner type systems), you can do
things like dispatch on the expected return type of a function. In a
dynamically typed language, you don't have any guarantees about future
computations, but in statically typed language, you can ensure that only
certain types (or a certain type) is returned from a function.

So in the extreme case, dynamically typed and statically typed languages
offer different kinds of expressiveness, and depending on what you want
to do, the one approach is indeed better suited for a problem at hand
than the other. If you don't want to take advantage of the specific
advantages, then it's rather just a matter of taste.

All other claims about static vs. dynamic types are bogus and unfounded,
and based on anecdotal evidence at best. Especially the typical claims
wrt efficiency and safety are unfounded. These claims are typically
demonstrated on small toy programs, and this doesn't prove anything.

Pascal