whether that matters or not depends on whether the logic error occurs because of a rare combination of events or as a result of a certain state and whether that state remains after recovery. if there is for example a logic error that causes the app to crash after say 10 minutes of runtime, or eg. at a certain message size, then a recovery will reset the runtime and it will work again. it will of course invariably fail again after another 10 minutes or when the same message is resent, because it is a logic error, and logic dictates that the error won't go away no matter how often you restart, but it will work in the meantime.

in other words, any error that doesn't occur right at start can be recovered from at least for all those operations that do not depend on that error being fixed.

This sound like a wild and very contrived argument.

Both because that memory leaks are normal is types languages - and does usually not matter in most serious applications - and because this class of errors is usually not what types catch.

Types have value when you 1) refactor and 2) have multiple people working on a code base.

The error you see when you don't have types is something like a BadArityError.