Statically typed languages apply typechecking as a "test" to the entire program at load time.
People have written and maintained code in typeless assembler, including for mission-critical systems. It's just more work and requires a different kind of rigor. The larger and more complex your system gets, the more useful typechecking becomes.
"Maintainable" is not a boolean, it's a cost function.
OTOH in strongly typed languages with rich type systems the actual code might be uglier and more complicated because you're constructing a proof of something. The property might be week (tests needed!) or strong (tests? what tests). Depends how far the rabbit hole you want to go.
At least that's my view on this.
It's rare for the programmer to actually produce proofs that a piece of code meets the spec given by its type[1]. Those proofs are generally produced by the type checker, possibly with occasional hints from the programmer.
1: Even in Coq, detailed specs for some code are typically given (and proven) separate from the code itself rather than in that code's own type.
In a dynamically typed system, every expression and line of code is a liability, and requires a large weight of tests to have any confidence that it might work.
Static typing eliminates entire classes of bugs. The cost of the up-front inconvenience to the programmer is tiny compared to the ongoing maintenance costs of possibly-incorrect, we-won't-know-for-sure-until-that-code-path-executes-in-production dynamically-typed code.
This is dependent on many variables but a good rule of thumb is that for any project bigger than a doddle, it's a safe bet to just fucking use a statically typed language.