Right that depends if you subscribe to the belief that null means the absence of a value `Option<T>` or does it mean the zero value `T`.
As the example of byte vs option<byte> either you want 256 states or you want 257. If you have 256 or 257 states you want to represent will decide which type is correct. The other choice of type is incorrect.
In some languages, these things are blurred because the language doesn’t let you choose a correct type for the state space, but I’m talking about the case where you can (coincidentally the set of languages I’d use).
E.g a boolean in java has two states true/false while a Boolean with capital B has 3 states true/false/null.
In that context you can choose type to represent how many states you have. E.g if it’s a field representing a cache of a bool value you can represent “not yet calculated” with null. It you were to magically convert null to false for a Boolean it only has two states! It’s now unusable for the purpose.
You need a 257th value to have a byte sentinel.
The whole point is to track the absence of a value. Why would one want to eliminate it?
null is way more trackable that some other special value like 0, -1, 999, "", etc.