We require a maturation period for coinbase outputs, because any two blocks at the same height will condemn at least one coinbase transaction to never exist in the best chain. If users were able to immediately spend coinbase outputs, perhaps even in the same block, even short reorgs could invalidate entire trees of transactions descending from the coinbase outputs of an extinct chaintip. This would create a big attack surface for scams, and incentives for reorg attacks.
While a reorg might return some non-coinbase transactions to the mempool, in organic chainforks block content would largely overlap anyway, and any transactions not included in either tip, would simply still be in the mempools of nodes following that chaintip. For the most part, a reorging miner would only be able to delay confirmation, but not permanently invalidate any transactions created by third parties. Transactions would only get invalidated in the case that a sender is actively creating conflicting transactions to doublespend while there are competing chaintips. In contrast, coinbase transactions could be written out of existence by a third party, rather than the original transaction creator.
Generated coins can't be spent until the generation transaction has
101 confirmations.
I find the quoted phrase from the accepted answer confusing, especially because it is easy to get lost in a meandering philosophical debate about when exactly a UTXO is spendable, when an output is spent, and at what point the confirmation count increases.
A transaction that spends an output of the coinbase transaction at height h, is eligible to be included in block h+100 or higher. Transactions that are eligible to be included in the next block will be accepted in the mempool, used to build block templates, and relayed on the network. This means that miners may include such a transaction in their block template when their chaintip has a height of h+99.