No it doesn't; the whole point is to avoid every type having a null state. You only define null states for those types for which it's semantically valid. For most types, you just don't have a null state and don't allow them to be constructed in an invalid state.

I'm not entirely sure what you're getting at here. Are you saying the author is arguing a call like

  new Customer()

should return something valid? I think the FP way would be to disallow constructor overloads with no arguments, as really, there's no reasonable thing to be done here. If you don't have all the necessary information to initialize a customer yet, you don't get to initialize one, and you pass around a partially applied constructor function instead.

ie, The argument is that (in pseudocode):

  Customer(name = "Jimmy", address = null)

is not really a customer if address is a necessary piece of information, so we should distinguish at the type level by passing around a function that takes the address and returns the correctly initialized Customer like so

  \addr -> Customer(name = "Jimmy", address = addr)

Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.

No, it implies that there must be a generic two-valued datatype to wrap every state:

Just t | None

You can have your null case, and avoid the null-pointer exception, default keyword, chained ? null-check hellscape in which we currently reside.

No, it implies that you can use your type system to surface the fact that a variable may have no values.