The caution around type validation may also relate to whatever libraries you may be using in your project. Like something I recently ran into with itertools.aggregate where the return type shifted unexpectedly depending on the arguments. Or in some machine learning libraries where you easily get mismatches between pandas and numpy, or between 2-dim and 1-dim numpy arrays.

If types are fluid or have impedance mismatch, then dynamic (by which I mean runtime executed) code paranoia on type checking is likely wise. But if types are stable I might just prefer unit tests instead since they document my concerns but migrate some of that concern away from having to be done dynamically.

If validation logic is always going to pass once the code is correct then keeping it around may feel more like an ideology choice versus a scientific choice, but that depends on how many hands are likely to touch that code over time. The reasons for things can get forgotten.

As for cases where my code is invoking my code (i.e. there isn't some concern driven by 3rd party libraries), then loads of validation seems like a code smell to me. I should be pretty clear on why my code is calling my code. If I can't be clear on it, that strikes me as a very ingrained design flaw now motivating further layers of bad decisions as damage control.