Adding special cases for the sake of completeness
This is a generalization of "complicated" number types, and is similar in scope to adding unnecessary fluff.
What I mean by this is that many challenges will try to make the problem well-defined for all possible inputs, when the challenge would have been much better if the set of inputs had been constrained more.
The challenge that prompted me to write this was multiply a string and a number. The basic idea is to repeat each character in a string a given amount of times. However, it also specifies what to do when the input number is negative, and the behavior is not a simple extension of the behavior for nonnegative inputs.
In my opinion, this special condition makes the challenge worse. I come to PPCG to solve interesting programming problems, and conditionally reversing a string based on whether a number is negative is not an interesting programming problem. It is unnecessary boilerplate that stops me from wanting to solve the challenge.
Furthermore, there are languages in which solving the problem is hard enough as it is. In the challenge linked above, one user decided to try and solve the problem in Retina. Retina was not designed for numeric handling, and the solution only worked for positive inputs. Thus, the edge condition stopped the answer from being competitive.
There are also languages such as Underload where input scope would be complete. In Underload, the most natural representation of numbers is whole numbers, and requiring that negative numbers be handled makes the challenge feel much more clunky.
In general, always choose the smallest set of inputs for which the problem is well-defined and interesting, and only require submissions to handle those. Anything else is edge cases, and handling edge cases is not fun.