I think ascribing PL popularity to striking the right tradeoff in this respect is leaping a bit far. It's compatibility and familiarity with predecessors, marketing dollars, etc. They tend to have C++ style syntax for example which is a similar path-dependence-formed quirk of history.

I want to point out that in practice, Common Lisp is also to some extent statically typed. The compiler will issue warnings if there are forms that it can determine (at compile time) would cause type errors at runtime. It's common practice to not accept code unless these errors are eliminated (one can even set up your compile system to abort when they are found.)

What it will not do is reject the program unless it can confirm that every expression will not cause a type error.

That's dependent on the implementation, SBCL is particularly good at it. Others may just let things pass like:

  (defun foo () (* 1 "aoeu"))

In SBCL gives me this:

  ; in: DEFUN FOO
  ;     (* 1 "aoeu")
  ;
  ; caught WARNING:
  ;   Constant "aoeu" conflicts with its asserted type NUMBER.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ;
  ; compilation unit finished
  ;   caught 1 WARNING condition

But in CCL it gives me no warnings at all and only triggers an error at runtime.

Schemer here, so this question may be silly, but can't you declare or declaim or proclaim or whatever (safety 3) to get stricter typechecking?

Those are only advice to the compiler, but importantly `safety` is about run-time error checking. Pushing `speed` higher and dropping `safety` to 0 means that runtime type checks might be removed for certain things, but it's not required to. Like if you've similarly declared that a variable definitely holds a `fixnum`, it'll believe you whether that turns out to be the right thing in the end or not. But again, it's advice. The compiler could leave those runtime checks in place, too.

An aside: never declare something to be a fixnum in Common Lisp. Fixnum means different things in different CL implementations, so this is a good way to get unportable code. Instead, use explicit integer range types.

Python is strongly typed. The weakness (such as it is) in python is that in historic idioms the type is ignored in favour of the interface (duck typing).