A product type forces the language to have a special "invalid" state for every type like Nil, and this reminds me of all the problems related to null handling I know from java - like forgetting to check for null / Nil.

A product type also allows returning weird states: no error and no value, or both error and value. I strongly believe that invalid states should be unrepresentable, rather than allowed by the type system and then fought by discipline and tooling.

Also, if there is actually an invalid state for the result type, and your type system has a sum type here, it can implement the sum type by overlaying it, producing machine code that's just as nice as for old school C or C++ programs yet programs that have readable sum types. The actual best of both worlds.

Rust for example promises that Option<NonZeroU32> is the same size (four bytes) as u32, even though it has much more appropriate semantics for some cases. I can't accidentally end up with a zero where I wanted anything else, and I can't easily forget to handle the None case where there wasn't a non-zero answer.

The return types of fallible functions map naturally onto sum types. By using product types instead there is a semantic mismatch. You get an error and a value but only one of those is valid. So you need to follow certain code idioms to get back the sum type semantics whereas this is something the type system could handle for you. Go's reasoning for that might be that they didn't want to have the complexity of sum types in the language, which is fair but is a tradeoff.