If you're just dealing with data structures as pure shapes, it's fine.
But people have been known to create overlapping shapes.  And if you
assume your pattern matcher will naturally sort that out, you're asking
for trouble.  I'm not saying you have to not be a deep thinker to want
pattern matcher, but pattern matchers will attract those who are not
deep thinkers because they seem to involve less direct programming.

Assume these are three independent abstractions:

 (defun make-simple-frob () 'frob)

 (defun make-foo (x) (list 'foo x))

 (defun make-frob (x) (list 'frob (list 'foo x)))

Now assume I do:

 (pattern-case v
   ((frob (foo $x)) ...action...))

in some language where (frob $x) is the pattern with frob being a
constant term and $x being a pattern variable.

Then if I give v as the result of (list (make-simple-frob) (make-foo 3)),
should it match?  If I give v as (make-frob 3) should it match?  Are
you sure that (list (make-simple-frob) (make-foo 3)) and (make-frob 3)
are intended to be semantically the same?

It's hard to make a direct comparison to strongly typed languages, since
strongly typed languages often don't give you the ability to examine
representational tokens, and so the extra tokens like the 'foo and 'frob
in the examples above would not be there to confuse things.  That makes
this comparison tricky.  But the feature of such languages is that many
such languages can't confuse:
  (pattern-case v
   (frob($x) ...))
or
  (pattern-case v
   ([bar, foo($x)] ...))
because the function wouldn't type-reconcile without knowing this.

Note well: You might assume punning is just bad and has no place in
programming, so you might say that such languages give you a leg up
and are automatically superior. I don't agree.  While this particular
instance punning has some problems, there are cases where punning and
dynamic inspect gives you very sophisticated effects that are hard to
simulate in static languages.

Language choices are not about Good vs Bad, they are about design
trade-offs: you trade away the things you don't plan to do in favor of
the things you do plan to do.  The hard part is getting that planning
right so you aren't pinned into a corner down the line.  Since Lisp
supports changing one's mind later, I tend to like that, but it comes
at some occasional costs, and I think there's a minor but manageable
cost on the issue of clarity of intent on certain intentional type
issues.  It's not a cost that troubles me because it buys other things
I care about.  Static typing feels like a stranglehold to me.  But
it's worth acknowledging that there are people who will be troubled by
these design trade-offs because they value things differently.