I see nothing false in rewording your statement to "a long-maintained large codebase requires continuous vigilance". Typing doesn't seem to matter with this. At least to the extent that we believe typing doesn't have a meaningful impact on the expected size, lifetime, and complexity of a codebase to solve an arbitrary problem. (With better type systems around it is neat to see statically typed languages quite significantly narrow the gaps in expressiveness though, and in some cases beat out 'trivially dynamic' languages.)
I know I've wasted time tracking down simple issues a static type system would have caught (or just due diligence by the coder -- and some of these issues I've caused myself! Though I really can't remember any insidious to find but quick to fix typo or type fail I caused, but I'm willing to admit to a possible selective memory bias), I've also wasted time tracking down simple issues a type system wouldn't catch -- even ones like Rust's, Haskell's, and dare I say maybe even Shen's? I also spend/waste a lot of time, probably the most time in total, tracking down complex issues that got past the type system and existing tests and code reviews and personal or team diligence, and these days most often in either Java or JavaScript, neither of which are particularly great poster children for their respective type systems. (I don't want to get into the strong/weak axis.)
Issues from NPEs or divide-by-zeros or undefined function calls, or stuff that goes through the type system's mechanisms to escape the type guarantees like reflection, casts to Object, void * , unsafe, serializing class names instead of values, etc., are annoying, a sudden power outage is also annoying. Some of that can be caught and prevented by more powerful languages, but still the time to fix those is nothing compared to more complex issues resulting in all sorts of incorrect behavior. There are so many more causes than type mismatches. It seems in your career the trivial bugs from typos are rare for you too. I'm not convinced the possibility of slight inconvenience those rare issues can create is worth the certain tradeoff in losing expressive power (especially if I can't use the most expressive static languages for whatever non-tech reasons) and possibly more, nor am I convinced a static approach is even the best one when you have languages like Lisp which support types well enough to error out when you call COMPILE on a bad form but still have huge flexibility.
I wonder if all this sounds like I'm a diehard C++ fan and don't need no stinking safe memory management tools because I never get segfaults or security problems. If it does I don't think it should, but it's really hard to explain why my perceived utility of static type systems is low without just appealing to preference, firsthand, or wise authority's experiences. The argument has been going on for decades by smarter people than me on both sides. In the end maybe it's just preference as arbitrary as a favorite color but rationalized to kingdom come. I at least don't draw my preference line so narrowly at static vs dynamic, there are plenty of static languages I'd use over JavaScript, and plenty of dynamic languages I'd use over C++.
I will ask about your experience though: how does it square with people like the author of Clojure? Is he just a god-tier outlier? I don't think one could argue he hasn't done his homework, or doesn't have enough real-world experience. It reminds me of a quip graphic I saw once, it was something like a venn diagram showing an empty intersection of "dynamic typing enthusiasts" and "people who have read Pierce's Types/Advanced Types books".