You sometimes need to model absence of a reference as well - that's why rust etc. have option/maybe types. Making every reference in the language possibly null was a terrible design mistake for algol, and making every value in the language possibly null was a terrible design mistake for SQL.
I disagree. It is not at all a design mistake in sql. You can have or forbid null values in tables. And you need that for many things. It is properly designed.
Rust or functional languages show you do not generally need null references, you have options instead. It is completely different.
Null in C or C++ is much more a very costly misstake. Missing data is just reality.
Data may be incomplete, the values unknown. SQL is designed for that. It is designed to handle reality. Whereas null references are not, they cause problems you do not need...
Data != reference
you can avoid the issue of allowing invalid references everywhere
you can not avoid incomplete data.
A database sometimes needs to model this case: the value is unknown: maybe the paper file you digitized was corrupted or destroyed, or other valid reasons this value is not known.
Whereas null references can be avoided, like in rust etc.