Null values exist, sometimes the value just doesn't apply and sometimes it does but you don't have it. That has to be modeled somehow.
For value types, they modeled that with a Nullable struct, which conceptionally is NOT a null reference, it always has a value and all of the methods on it always work (Value sometimes throws an exception, but that is correct behavior under the circumstances).
Reference types historically model this fact with null reference/pointers. That is not actually a problem. As has been recognized recently, the REAL problem is not having a way of requiring that a reference type MUST HAVE a value.
Without that, method calls that take or return reference type, break the programmers ability to reason about what the program will do. The method can expect that the value is not null, but there is no way to enforce it. Which means the programmer either adds checks manually, checks which are mainly useless and get duplicated time after time, or lets the program crash when someone inevitably makes a mistake and doesn't provide a value. Worse, when adding the checks to try to prevent a crash, the programmer has to figure out what to do when a value that MUST be there, isn't.
Non-nullable references fix this -- the compiler knows when a value might be null, and prevents a reference from being passed to or returned from a method where it could be null but MUST not be. Now you can have the equivalent of method(primitive value) where if you try to call it with method(new Nullable()) it won't crash, because it just won't compile.
TL;DR version: nullable types are not the same as reference types, because it ONLY makes sense to accept or return them when the value could be null. And you can have methods that return the non-nullable value type. With "regular" reference types you have to accept and return them regardless of whether the value can be null or not.