Por qué podríamos eliminar CampoNulidad y por qué va a continuar

Os enlazo un artículo muy breve pero muy interesante sobre algo que leí hace ya mucho tiempo (cuando lanzaban C# 2.0) y que después no había vuelto a recordar por lo que no había podido usarlo: la facilidad con que se crean tipos Nullables en .net a partir de otros tipos que no admiten Null (tipos de valor, como int, DateTime...), usando el tipo genérico Nullable<>.
Usando esto, no es necesario tener 2 propiedades para un campo de la base de datos que puede ser nulo. Antes creábamos dos propiedades, una DateTime (por ejemplo) y otra bool. Ahora basta con crear una Nullable, lo que nos facilita el trabajo doblemente: de la entidad a la base de datos, el ORM no necesita mapear dos propiedades, sólo una, asignado un valor si es eso lo que hay en la base de datos, o un null si encuentra un DBNull: exactamente igual que al mapear objetos: menos trabajo y más simple. Por el otro lado, al establecer el enlace entre controles y entidades (Data Binding), podemos conectar un control directamente con una propiedad Nullable, cuando antes si lo hacíamos no se consideraba la otra propiedad buleana y a veces salía un valor cuando realmente era un Null y no debía verse nada. Ahora incluso podemos definir en el DataBinding el valor a mostrar cuando nos encontremos null, de forma muy sencilla.
Total, que tendríamos que eliminar el atributo CampoNulidad, así como los parámetros IgnorarNulos y ValorSiNulo del resto de atributos Campo.
Pues no: en primer lugar, los parámetros IgnorarNulos y ValorSiNulo siguen teniendo sentido para las propiedades en las que no nos aporta significado si un valor es nulo o no, en los que aunque hayamos leído un nulo ahora vamos a guardar un valor.
Y en segundo lugar, pueden seguir existiendo casos en que la entidad quede más clara si dividimos el nulo en una segunda propiedad, por ejemplo en el patrón DeBaja, donde contamos con 2 propiedades: DeBaja y FechaBaja. Queda más claro preguntar si DeBaja que si FechaBaja == null. Por lo que las posibilidades de mapeo se mantendrán, pero es obvio que se usará mucho menos el CampoNulidad, definiendo en su lugar una única propiedad de tipo Nullable.