(2) creates a Date using a ParseStrategyT, given the ParseInput that T accepts, as long as T produces Dates from parsing (i.e. ParseInput -> T -> ParseOutput == Date). This is the general method: you could create a ParseStrategy whose ParseInput type is anything, and if you called Date.init(_:strategy:) with that strategy, this would get called
(1) does the same, but doesn't tie the input Value directly to T.ParseInput: if T expects an input value of String, you can still provide anyStringProtocol-conforming value (e.g. String, SubString, StaticString, etc.) to that version of the method as it can convert it to String and then pass it to the strategy (i.e. Value -> ParseInput == String -> T -> ParseOutput == Date)
In other words, (1) lets you pass more String-like values to the initializer and still let you parse them using a ParseStrategy that more strictly expects String input.
(As for ambiguity: the compiler typically prefers "more specific" versions of methods over more general ones [and can take into account deprecation] in order to avoid ambiguity without needing more input.)