> Lisp isn't any one thing, it's a language family.
Which is rather the problem. Types, in particular, are only useful if everyone has them - optional add-on typing has been tried for many languages, but I've never known it be successful.
Typed Racket <https://docs.racket-lang.org/ts-guide/> is pretty successful in the Racket community. It's also prompted some pessimistic papers about gradual sound typing, since it's hard to avoid a performance hit when imposing type safety on untyped code using contracts. On the other hand, that performance hit is in part typechecker/compiler implementation dependent and in part dependent on the granularity of the added typing (e.g. typing modules or functions vs typing subexpressions).
Typed Racket code often gains a speedup over untyped Racket, since sound typing allows the elision of contracts and other runtime overheads for safety. There is no penalty at all for invoking Typed Racket code from untyped code, either in terms of performance or in terms of what the untyped-language programmer needs to know.
Note that we've made big improvements in the performance of Typed Racket's generated contracts just since that paper was written, so many things are now better.
My point was that making generalizations about Lisp is like making generalizations about languages with C-like (perhaps more correct ALGOL-like) syntax. Most people wouldn't make a statement about Java and assert that it applied to C++, too. This is why saying that Lisp has no type system doesn't make much sense. There are many completely different languages that use s-expression notation, and they all have different feature sets, much like all the C-like languages.
Which is rather the problem. Types, in particular, are only useful if everyone has them - optional add-on typing has been tried for many languages, but I've never known it be successful.