Databases are different beasts from normal programming languages.

Because the schema of a table is set all the data needs to be present when saving the information to a row. However many of this data may not be required to create a valid representation of a model object once loaded in your code. Requiring that all data must be non-null and populated will mean that these non-required fields will have to contain a value and yet they do not have one yet, they are "unknown".

Imagine having to fill ALL fields on web forms ALL the time since they cannot be null in the database they must receive a value... a recipe for insanity that is !

You could set some reserved values to represent the absence of data, an empty string, a specific number, a specific date etc depending on the data type but what value to choose ? Then you need to make sure that everyone agree that these arbitrary values actually mean "unknown" and not "January 1st 1970" for example.

Having a single universal value for everything that is unknown I find much preferable than using some set of arbitrary constant values. I'm not saying constant values are bad and null is better, if your model is well served by a constant to represent this information then by all means use that but there are many situations where a null is just what fits best. For all null haters, this is a situation if null was denied it would have to be invented !

Seeing how pervasive the concept of "unknown" is in a database then yeah, I'd say that making the values nullable a default makes a lot of sense.

Going deeper and looking at other answers here I would not be surprised to learn that nulls are not just a "language feature" but an integral part of the underlying theory on which SQL is based. One can remove C (the speed of light) from the relativity, but the concept of absolute maximum speed remains and must still be expressed so it will be back in some shape or form.

Databases are different beasts from normal programming languages.

Because the schema of a table is set all the data needs to be present when saving the information to a row. However many of this data may not be required to create a valid representation of a model object once loaded in your code. Requiring that all data must be non-null and populated will mean that these non-required fields will have to contain a value and yet they do not have one yet, they are "unknown".

Imagine having to fill ALL fields on web forms ALL the time since they cannot be null in the database they must receive a value... a recipe for insanity that is !

You could set some reserved values to represent the absence of data, an empty string, a specific number, a specific date etc depending on the data type but what value to choose ? Then you need to make sure that everyone agree that these arbitrary values actually mean "unknown" and not "January 1st 1970" for example. Null aversion can take many forms and take you on long convoluted detours just because someone said nulls were bad. How complex are you ready to get just to avoid dealing with nulls ?

Having a single universal value for everything that is unknown I find much preferable than using some set of arbitrary constant values. I'm not saying constant values are bad and null is better, if your model is well served by a constant to represent this information then by all means use that but there are many situations where a null is just what fits best. For all null haters, this is a situation if null was denied it would have to be invented !

Seeing how pervasive the concept of "unknown" is in a database then yeah, I'd say that making the values nullable a default makes a lot of sense.

Going deeper and looking at other answers here I would not be surprised to learn that nulls are not just a "language feature" but an integral part of the underlying theory on which SQL is based. One can remove C (the speed of light) from the relativity, but the concept of absolute maximum speed remains and must still be expressed so it will be back in some shape or form.