Hi Vincent,
I'll add a bit to Ben's explanation, all of which is correct.
* The boolean schemas are trivial shortcuts that always validated (true) or always fail to validate (false). They are most commonly used with keywords like "additionalProperties", which take a schema as a value. But often you simply want to say that no additional properties are valid, and you use false in that case. Or to explicitly say that all additional properties are valid, with any values, you use true. A few drafts ago, we decided that the true and false schemas should be available everywhere instead of only for two specific keywords.
* JSON Schema is extensible, so the meta-schema cannot fail in the presence of extensions. If you want to use a more strict meta-schema to catch additional errors specific to your usage (let's say you always want to require a "type" field, for instance), then you can write your own meta-schema. This is what I have often done- for testing internally, I'll use a strict meta-schema that enforces our team's style and finds additional bugs. And then for publication, I'll use the standard meta-schema for compatibility.
JSON Schema is not like object-oriented programming. In OOP an empty class allows nothing- there are no defined data members or functions. In JSON Schema an empty schema allows everything, as there are no defined constraints.
thanks,
-henry