Fundamentally, it's because we want each challenge to be about one thing. "Verify that the input is an integer" might make an interesting challenge in its own right. However, once the shortest way to do it in any given language is known, it doesn't make much sense to copy the code for that into every challenge which takes an integer as input; it'd be boilerplate that distracts from the main problem.
Additionally, not all languages are even capable of determining if input is in the correct form. For example, there are languages in which values are opaque objects that can be "forced" in order to determine properties of them, but the process of forcing can run arbitrary code. (This is quite a large set of languages, running from lazy functional languages (like Haskell) at one extreme, to languages where the only way to read input is to evaluate at another (this covers both practical languages like m4 and esolangs like Underload).) In these languages, an "integer" is something that can be forced to provide typical properties of an integer (such as being positive), and without side effects or nontermination. But there's no way in general to determine that a program will have side effects, and because the object is opaque, you can't deduce anything about it before you try to force it.
Finally, there's a conceptual point; typically challenges here on PPCG are for things that could reasonably be used as part of a larger program (our default for challenges is "program or function", mostly because full programs sometimes have less boilerplate). In such a case, you can assume that the larger program in question would be responsible for the input validation, and thus would pass only validated input to the code that you're writing.