When you restore a wallet from seed, you scan the blockchain to attempt to decrypt the destination of each transaction, to see if any of those transactions were destined for you. This process will discover which amounts of Monero (a.k.a. outputs) are owned by your wallet.
If you know you had not received any funds prior to a certain date, you can save time by only scanning the blockchain from a more recent point in time. Block 1720000 was created on 2018-12-05 (see https://xmrchain.net/block/1720000), so if you restored from this height you would not see any funds in your wallet that arrived prior to that date.
The default subaddress lookahead is 50:200, which means creating a lookup table of 50 accounts with 200 subaddresses each, totalling 50*200=10000 subaddresses to scan for initially. Generating this lookup table requires computation, so by reducing the number you initially scan for, you can reduce the Ledger setup time. This is mentioned here: https://github.com/LedgerHQ/ledger-app-monero/blob/master/doc/user/bolos-app-monero.rst
By reducing the lookahead to 3:100, this means that if you'd created 4 accounts and received funds to the 4th account but not to the first 3, the Ledger would not notice any of the funds received to account 4 when scanning. Similarly, if you'd created 101 subaddresses in the first account, received funds to subaddress 101 but not to any of the first 100, then the Ledger would not notice the funds that arrived at subaddress 101. But if you had received funds at subaddresses 90 and 101, then when Ledger saw the incoming funds at subaddress 90 it would then automatically start scanning further ahead by another 100 subaddresses in the future, so that it doesn't miss incoming funds. For more information, see Funds received from subwallet are not showing
TL;DR: By specifying a restore height and smaller lookahead range, you decrease the computation required by the Ledger and can therefore restore your wallet faster. This comes at the risk of the Ledger missing incoming funds if you are restoring a very old wallet or if your subaddress usage pattern is such that you issue lots of unused subaddresses.