SQL Server (and hence Azure SQL Database) has a cost based query optimiser (QO). This means it generates a number of logically equivalent but physically different query execution plans then chooses the cheapest one according to some internal, proprietary cost calculation model. So, trivially, it chose to do this two-index join because that was cheaper than any alternative plan it considered.
The question then becomes why would this be cheaper than using a single index. For an accurate answer we would need the table definitions, statistics and the query plan. However I'm willing hypothesise.
The two indexes have the same keys (ColA, ColB) but different included columns. This means "missing" is narrower and more rows will be able to fit on a page. So less IO will be required to read a given number of rows from "missing" compared to "WillTest". SQL Server's cost model assumes all data read comes off disk so reading narrower indexes will be preferred if they can fulfil the need at hand. I'd guess that the query has predicates on ColA, ColB and/ or ColC and that using "missing" was the cheapest way to satisfy these.
Why then pull in "WillTest". My guess here is that further columns from this table were required to satisfy the query - either in the predicate or as returned values. The cheapest way to find these is in the INCLUDES of "WillTest". The alternative would be to read the base table which likely is even wider than "WillTest" and even more expensive to read.
You could test my guess using table hints. Note the overall cost of the query as it is now. Then hint it to use only one of the indexes, then to use only the other, noting the cost for each. I'd think the current plan has the least cost. Costs are a black-box however so this may not be compelling.
An alternative explanation is that you have an index intersection.
You call it an "unnecessary" join. Likely it is not. Each index contributes to satisfying the needs of the query. Click on each Index Seek and press F4 (properties). The predicates and defined columns will show what part each plays. Doing it by joining indexes is only one possible implementation. Others are possible. The QO thinks this is the cheapest.
Finally note that it is at least possible that the optimization process errored in some non-terminal way and this was just the least-bad plan it had at hand to run.
