The reason for that being not that good basically has the same reason as with coercion rules in weakly typed languages like JavaScript.
If I'm passing a string to an int column, there is most likely an issue in my application code. If there currently is none, there might will be.
For example, I might have forgotten to parse the string properly in my application code. If I'm doing '10' * 2 in JS, it returns 20. If I later change it to '10' + 10, it will be '1010'.
Say I then save the result of that compilation in the DB. Raising on '1010' would have prevented me from persisting the error and gave me an opportunity to investigate the situation. Without an error, there will be a much harder debugging session.
These coercions were popular back in the 90s/00s, which is why I think most DBMs have them. At least that's why JS has it.
If I'm passing a string to an int column, there is most likely an issue in my application code. If there currently is none, there might will be.
For example, I might have forgotten to parse the string properly in my application code. If I'm doing '10' * 2 in JS, it returns 20. If I later change it to '10' + 10, it will be '1010'. Say I then save the result of that compilation in the DB. Raising on '1010' would have prevented me from persisting the error and gave me an opportunity to investigate the situation. Without an error, there will be a much harder debugging session.
These coercions were popular back in the 90s/00s, which is why I think most DBMs have them. At least that's why JS has it.