Post History

In my opinion, all of the downsides boil down to two objections:
* It isn't idiomatic (in C# and VB.⁠NET)
* It's slightly less performant

The fact that it isn't idiomatic means that, as you noted, it'll often need to be translated at API boundaries. It also means that your coding style might vary from what other developers expect and from what you yourself use when working with other data types.

The fact that it isn't as performant as an unboxed nullable value is usually something you can ignore, unless you know that it isn't, and then it tends to be a hard blocker.

The advice I'd give to a C# developer on my team would be consider the broader, ‘high-functional’ programming style that `Maybe`/`Option` is a part of—immutable data objects, lots of anonymous functions, pattern matching via the newer `switch` expressions or via fold-like functions, heavy use of the type system to express invariants. That style brings lots of benefits and lots of friction with existing .NET libraries (except for libraries that target either F# or enabling this programming style in <strike>lesser</strike> other .NET languages). If it's worth it, go all in. If not, picking and choosing this style for some data but not others is probably more trouble than it's worth.

(As for ‘monads’, the fact that `Maybe` is monadic is worth very little to a .NET developer. The real value of recognizing abstractions like functors and monads comes when you can actually, y'know, abstract over them. As far as I know, .NET still doesn't have higher-kinded polymorphism, which means that goal remains out of reach. If you want higher-kinded types in a language that still allows a C#-like experience, Scala is waiting for you to switch allegiance from the CLR to the JVM. Back in .NET-land, ‘monad’ can only mean a particular code style as opposed to actual expressive power, which is why that's what I focused on above.)