Using “hardened” receiving addresses provides some extra security in case of a private key falling into the hands of an attacker. Hardened addresses prevent other private keys in the wallet from being exposed, limiting the scope of damage from an attack. If the private key corresponding to a regular non-hardened address were stolen along with the master public key of the wallet, the other private keys in a wallet could be stolen as well.
However, there is a trade-off to using hardened addresses. Regular addresses are derived from public keys, but hardened addresses are derived from private keys. So to generate new hardened addresses requires access to private keys. This means either that private keys would need to be kept on our servers or that the client’s hardware wallets would need to be accessed whenever they wanted to generate new addresses. Both of these options are unacceptable.
We take a different approach to security. We focus on securing and quarantining private keys on offline hardware wallet devices. Using regular, non-hardened addresses helps us enforce this quarantine since the private keys never have to leave the device and hardware devices may remain idle for long periods of time.
Using non-hardened addresses creates an additional vulnerability in case of an attack which manages to steal one private key from a wallet device, but not others. We judge that such a scenario is unlikely. If an attacker finds a vulnerability in a wallet device that allows them to steal the private key corresponding to one address, it is likely that they will be able to steal the other keys also. This vulnerability is an acceptable trade-off considering the stronger private key quarantine that is available for users of non-hardened addresses.