Just a very minor possible reason:
It could make it a bit easier for an author who was creating a JSON file by editing a blank template that might be made available. The author would be able to skip optional strings by leaving them null, instead of needing to delete the entire objects. Of course, ideally a program or form would be made available to authors, instead of a raw template. However, I think your “it’s liable to be a mistake” argument holds more weight towards the desirability of requiring at least one character.
I don’t think so. Keep in mind that the schema is just something that can be used by some kind of validator (or form generator) program to assure that a corresponding JSON file is correct. That validator can choose to do whatever it wants with the information provided in the schema.
Also, unless a loader program actually uses the schema to validate info.json, it can’t automatically trust info.json to be correct. The loader program must itself assure that the data provided is compliant with what it expects.
This is why I’d like to also provide maximum string length limits. Even if it’s just enforced manually by the author browsing the schema, it will prevent problems like “How was I to know that the loader would reject my title because it’s 700 characters long? You didn’t specify a limit!”. We should agree upon and document the maximum allowed length of all string fields.