Generally having a value is more semantically correct, and clearer. Let's take the message_count field as an example which is an unsigned int, if that allowed null then essentially you could have values > 0 which are valid, 0 would be valid and null would be valid. In that particular example, what use is null? What does it mean when compared to 0? Does it mean 0? If it means 0 why not just use zero? etc.
Generally the only time in XF where we allow nulls is for fields where a default value isn't permitted (blobs, text fields etc) but even then we use the entity value to set a default value.
There can be use cases for using null or where null is more semantically correct, but otherwise if you can use a semantically correct default value, why not?
Sometimes my table is not fully populated. An example is table plane with fields id, name, image. When a new plane is added and I do not already have a picture, I would use null. It might be the best way to use another plane_image table, but it would make things more complicated. I think in this use case, null makes sense?
Yep, I'd agree that usage makes sense. In that use case, null represents the absence of something. Arguably an empty string would too, but it likely makes more sense using null there than it would in the integer case.
It allows the value to be nullable in the entity itself and be valid, it's not totally related to the database structure (though I suppose it sort of is). Common scenario is auto increment fields. When you save it, the value has to be null so MySQL will add the AI value to it. If it was cast to zero as would be the default behaviour in the entity for an INT field, then it would actually be inserted with that field as zero and it wouldn't get an AI value.
Other scenarios would be simply where you want casting to happen in the normal case, but the field itself in the schema is nullable and you would like to allow null as a value.