Why are case limits or border cases never required in questions?
For example what to do if some variable overflows in calculations or some argument of the function is wrong or it is the wrong type. Why are limits of arguments for a function not discussed? Etc.
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.
The immediate reason is "the challenge author does not require it" and that can vary between authors, and even between challenges by the same author.
The underlying reason that many challenge authors do not require error checking or dealing with certain edge cases is that these tasks are not relevant to the challenge. However, this is not always the case, and there are examples in between the extremes. For example, a challenge may require dealing with an input of 1 that requires a different approach, but not an input of 0. The challenge author decides whether dealing with corner cases or overflow would make the challenge more or less interesting.
The vast majority of challenges do not require dealing with completely invalid inputs, as that is a separate task that distracts from the challenge and adds unnecessary extra work. Many do require that the code work for a defined range of input values though, while others make a requirement somewhere in between, such as "working in principle" for large values, even if time or memory constraints, or the available data types, prevent this in practice.
The requirements of a challenge may also be dictated by the author's desire to allow more languages to be able to compete, but this again varies between authors and challenges, and it is not required that every challenge be approachable by every language. We just avoid excluding languages deliberately.
It is because if it would request to threat error cases their language could not
or if it is possible their solution will be more character rich than Java C or Axiom...
Sono cattivo, vero?