Option.None is useful to indicate that the value is optional in type signatures or that the return value is optional in type signatures. An API documentation that has public Option foo(B b) indicates that the B is a pure value (is not optional/not null) and that the return value has the potential to not be set. public A foo(B b) would indicate that the return value is not optional and that a meaningful value will always be returned. Option also handles primitives because null can't be assigned to primitive types, likes integers or doubles.
An example would be searching a list of primitives. public Option find(List primitives, Func predicateWhereCondition) means that the item in the list matching the where condition may not be found. The classic method of searching usually defaults the value to return value to -1 in public int find(List primitives, Func predicateWhereCondition) when the item isn't found, which is nonsensical when the list can contain negative integers.
If you don't want to unwrap the value, then why aren't you returning the Option type in the return type signature? When you litter your code with foo.unwrap(default), you're being forced to handle the missing foo values. Developers forget to write code on every foo return because they assume that the value is pure, meaning that public List foo() will always return an empty list rather than a null value.
Java has checked exceptions. C# has unchecked exceptions. Option types are similar to Java's checked exceptions (except checked exceptions are more like the semantics of the Either monad). You're not forced to catch the exception. You can throw the exception further up the stack if it doesn't make sense to catch the error. You're not forced to unwrap the Option type. You can throw it up the chain. Why shouldn't your function have the return signature of Option.None if you don't want to deal with unwrapping at the level you're unwrapping your Option types at?