I really like option types in languages that were designed around them, but given Dart's history as an imperative C-ish language with millions and millions of lines of code out there, I think nullable types are a better fit for the way users think about and work with the language.
It's really hard to do both approaches. (The fact that Java has an Option<T> type, but all references to it are also nullable, is sometimes a source of chagrin and sometimes hilarity to me.) If you want a nice user experience, consistency across the ecosystem is huge.
So when we decided what to do about statically checking for null reference errors, we went with nullable types (the same as Kotlin, TypeScript, and C# do) instead of option types (Swift, Rust, etc.). I wrote a long thing about my thinking on it here if you're curious:
It's a real trade-off. There aren't perfect solutions. Option types have some nice composability properties, but they tend to be more verbose and don't play as nice with the imperative control-flow heavy code that's idiomatic in C-derived languages.
