I fear I must be misunderstanding your points. Are you really stating that, in order to know what you can do with data, you need just need to inspect it at
runtime? Or that types only protect you from typos?
Types allow the compiler to do a lot of validation before your code is even executed, removing whole classes of bugs before they even have a chance to manifest themselves. You thought that value was an int and divided it by two? It was a string. I'm glad I didn't have to wait until runtime to find out about it, or to write tests to make sure that every single code path to that division results in the value being, in fact, an int.
Types allow developers to trust whatever data they receive without feeling the need to protect against hostile, or less experienced, application programmers passing incorrect data. They allow you to know, with absolute certainty, that what you wrote can only be executed the way you meant it to be executed (whether that's correct or not is another question altogether). A function in a dynamic language is never complete, you never know what data, or shape of data, you will receive. Types buy you that certainty.
Code efficiency is not the point - developer efficiency is. When you can trust your data, you can focus on what your code needs to do - that's usually complicated enough without adding the complexity of not being able to trust a single value.
The main argument against static languages is that, in their struggle to be sound, they end up not being complete - and it's absolutely true: there are perfectly legal programs that you can't write with a static language, but that a dynamic one would run without batting an eyelash. Duck-typing comes to mind, I'm sure there are other examples.
Another argument is that type systems get in the way of what you want to do. There are a few cases where it's true - see the point just above. But in my entirely anecdotal experience, the vast majority of times someone complains the compiler won't let him do what he wants, it's because what he wants to do is not correct. The complaint is not that the compiler is too restrictive - it's that your bugs are shoved in your face much, much more frequently and quickly than they would if you had to wait for runtime. And that's a good thing.
Types allow the compiler to do a lot of validation before your code is even executed, removing whole classes of bugs before they even have a chance to manifest themselves. You thought that value was an int and divided it by two? It was a string. I'm glad I didn't have to wait until runtime to find out about it, or to write tests to make sure that every single code path to that division results in the value being, in fact, an int.
Types allow developers to trust whatever data they receive without feeling the need to protect against hostile, or less experienced, application programmers passing incorrect data. They allow you to know, with absolute certainty, that what you wrote can only be executed the way you meant it to be executed (whether that's correct or not is another question altogether). A function in a dynamic language is never complete, you never know what data, or shape of data, you will receive. Types buy you that certainty.
Code efficiency is not the point - developer efficiency is. When you can trust your data, you can focus on what your code needs to do - that's usually complicated enough without adding the complexity of not being able to trust a single value.
The main argument against static languages is that, in their struggle to be sound, they end up not being complete - and it's absolutely true: there are perfectly legal programs that you can't write with a static language, but that a dynamic one would run without batting an eyelash. Duck-typing comes to mind, I'm sure there are other examples.
Another argument is that type systems get in the way of what you want to do. There are a few cases where it's true - see the point just above. But in my entirely anecdotal experience, the vast majority of times someone complains the compiler won't let him do what he wants, it's because what he wants to do is not correct. The complaint is not that the compiler is too restrictive - it's that your bugs are shoved in your face much, much more frequently and quickly than they would if you had to wait for runtime. And that's a good thing.