It's not on the stated list, but null pointers is a classic expedient unsafe shortcut for those too lazy to design a better type system. C is full of such shortcuts (c.f. Algol 68).
First of all, that has nothing to do with the UNIX philosophy, second of all, it has nothing to do with type theory. Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C, allocating it on the heap (because you wouldn't be able to return it if it were stack-allocated), and then returning a pointer to it, whereupon C's actual type system would happily complain about mismatched types if you tries to use this type without deliberately accessing its internal members, at which point you're doing exactly as much intentional effort as if you used a convenient accessor macro that checks to make sure it's not the nil case. While I agree that C (and its type system) could be much better, fixing the problem is not quite as simple as "just design a better type system".
> Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C
1. No parametric polymorphism, but I'll let you move the goal post with us macro-ing a bunch of monomorphized nullable pointer types. It still sucks because
2. No static checks against nullable values in the non-Maybe case, no ergonomic pattern matching in the maybe-case
Moreover, let's be real. Nobody writes new C in a vacuum, and given that that ecosystem is very mature, there's no changing course now. But safety techniques are only as good as their weakest link---their use must be enforced everywhere. The damage is done and irreparable with C.
Parametric polymorphism is needed to implement “Maybe” as a generic type that can be applied to another type, but you can implement individual concrete Maybe X types without it.
You could possibly use macro programming to do it “generically” at a level outside the type system.