Cryptonote is more sensitive to reorganizations than Bitcoin.
In Bitcoin, if N blocks are reverted, all the transactions they contain are now ready to be mined again (or might already be included in blocks that replace those N blocks).
In Cryptonote, if N blocks are reverted, any transaction that include an output created in those N blocks is also (probably) invalid, since outputs are refered to by their index within an amount. This means those transactions will be rejected, and will have to be recreated. Bear in mind that, due to ring signatures, the recipient of a coin is not the only one to include it in a subsequent transaction. Third parties also do.
Now, there are ways around that. The simplest is to prevent outputs from being used within a given number of blocks. Another would be to include public keys of inputs in a transaction, instead of indices. This would increase the size of a transaction markedly, though an optimization could be made when storing the transaction (turning public keys into their index). However, this is a bit complex, since you have to keep the public keys for a while, in case those outputs end up in a reorg.
As a last point: this has to be both a wallet and daemon rule, otherwise someone would be able to tell whether an input that was created very recently is the real one or not.