Why does SQL Server start REDO phase from minLSN instead of last CHECKPOINT?
The Database Checkpoints doc says that


  For performance reasons, the Database Engine performs modifications to
  database pages in memory-in the buffer cache-and does not write these
  pages to disk after every change. Rather, the Database Engine
  periodically issues a checkpoint on each database. A checkpoint writes
  the current in-memory modified pages (known as dirty pages) and
  transaction log information from memory to disk and, also records the
  information in the transaction log.


So the CHECKPOINT is not directly related to transactions, instead it's related to dirty pages which might not belong to the same transaction and that explains why the recovery process of a database must consider the MinLSN instead of the last CHECKPOINT as you suggested. 

If you take a look at the structure of the Transaction Log Physical Architecture, you'll see that a checkpoint can happen in a VLF that is in front of the oldest active VLF as the following picture ilustrates:



With that in mind, think that a really long transaction (T1) started using Virtual Log 3 and only completed by the end of Virtual Log 4. During the execution of T1 another transaction happened (T2), but this one started and completed after the CHECKPOINT. Now imagine a crash happened. If the recovery process would consider as starting point the CHECKPOINT, it would be able to redo T2, but not to grant a consistent state to the recovered database for the crash of the database happened after the CHECKPOINT but before T1 had completed, leaving half a transaction registered when it should be rolled back.

You can also see that example on the picture in your question where the Oldest uncommitted Tx started before the Last Checkpoint.