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.
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.