I'm failing to imagine a scenario where implicitly typing either of these would benefit me as the developer - having those elements remain statically typed seems like "the right thing to do" given their role in defining public code contracts. Could you help me understand why this is a bad thing?

They are always statically typed; no one is talking about dynamic typing. Inferred types are just as static as any others.

Example: Dictionary<string, Func<string, int, Dictionary<string, string>>> somedic = new Dictionary<string, Func<string, int, Dictionary<string, string>>> { ... }

Is almost entirely better served by

  let somedic = dict [ ... ]

Your point about defining a public interface is separate. If you have a specific API that you cannot break, then feel free to type it out all you want. If you feel a piece of code is confusing or unclear without an annotation, go ahead and add it.

For the majority of code, having to specify the types is an exercise in verbosity, nothing more. Unless you're only writing public libraries with no internal implementation, I don't see how there's not a scenario.

I agree that doing that type of inference would be convenient - I deal with a lot of nested generics like that on daily basis.

But this is just syntactic sugar, and the var keyword already takes care of the left-hand operand in this equation. Generic functions also do a reasonably good job of type inference under this set of circumstances, although I've found that generic delegates and lambdas not so much.