Before hierarchical deterministic keystores were introduced to Bitcoin Core (to my knowledge called BitcoinGUI earlier, don't remember when the name was changed to Bitcoin Core) the legacy keystore contained independant random private keys. Such wallets with a keystore of random independant private keys needed to be backed up regularly. And it was possible to loose keys and funds under certain conditions when you restored an old backup.
Bad things happened under the following circumstances:
The wallet created new fresh private keys in batches when needed, i.e. when the number of unused private keys were exhausted, e.g. in batch sizes of 100 keys (don't remember the exact batch size). Suppose your recent wallet backup contains a keystore size of 500 keys with only a marginal number of unused keys left (you don't see that). You make a few transactions which exhaust the number of unused keys and this triggers the creation of a new batch of fresh keys (keystore size now 600), you still make a few transactions which transfer funds as change to addresses of those newly generated keys (or you consolidate your UTXOs to such "new and fresh" addresses). For whatever reason you still don't have a backup of your wallet with the bigger replenished keystore.
Now something bad happens which forces you to restore from your most recent wallet backup file (which has a smaller keystore size!). This leads to the loss of the most recent new keys batch and subsequently in this case to a loss of funds. In the worst case you loose all your coins in this wallet!
This unwanted situation was the main problem of a keystore of independant random keys. In a HD wallet all present and future keys are deterministic and recreatable from the HD seed key. With a HD wallet it doesn't matter which wallet backup file you restore, you can't loose keys. You may only loose some commentary metadata of addresses/transactions, but nether any keys or any past transactions (a blockchain rescan may be needed after a restore of a backup wallet file).