I don't think Hoare said that null was his mistake. I believe he said that the null reference was his mistake. In other words, null is not a reference, and treating null as a reference in all contexts conflates optionality and referentiality. The problem is that referentiality and optionality should be orthogonal concepts in type systems.
Nullability/optionality is clearly useful. References/pointers are clearly useful. The problem is making them a single concept in a type system, thus requiring all references/pointers to be nullable and making it very awkward (such as forcing the user to manually declare a wrapper type holding a boolean and the wrapped value) to have optional values without making them references.
The conflation of referentiality and optionality in the most popular static type systems also bleeds over into mental shortcuts used by many programmers in dynamically typed languages when thinking about the types of parameters expected by functions/methods. Had Algol W, C, etc. kept optionality and referentiality separate in their type systems, I think Python/Ruby/Lisp etc. programmers would likely think more carefully when passing None into fuctions/methods.
Lisp doesn't have None; it has nil. The Lisp nil was not inspired by the conflation of referentiality and optionality in popular static type systems. It predates them.
The conjecture about dynamically typed languages was regarding the cultural effect of the popularity non-null-safe static type systems on the current practice of coding in dynamic programming languages. It wasn't a conjecture about the structure of the type systems in those dynamically typed languages.
I find that even less plausible. I don't suspect that the null reference practices in, say Java, have any influence on the way people work in Lisp.
Optional parameters in Lisp take on a value of nil when the argument is omitted (unless a different default is specified). Various search functions return nil when an item is not found: find, member, gethash, ...
The practices around these conventions may, at times, resemble work in static languages with null references, but there is no cause-and-effect there.
Nullability/optionality is clearly useful. References/pointers are clearly useful. The problem is making them a single concept in a type system, thus requiring all references/pointers to be nullable and making it very awkward (such as forcing the user to manually declare a wrapper type holding a boolean and the wrapped value) to have optional values without making them references.
The conflation of referentiality and optionality in the most popular static type systems also bleeds over into mental shortcuts used by many programmers in dynamically typed languages when thinking about the types of parameters expected by functions/methods. Had Algol W, C, etc. kept optionality and referentiality separate in their type systems, I think Python/Ruby/Lisp etc. programmers would likely think more carefully when passing None into fuctions/methods.