I’m with @tromer and @adityapk00 on this; there’s very little we can do on desktops to protect spending keys from endpoint compromise, given the current and widely-inconsistent state of desktops. It’s one of the reasons we’ve not spent cycles to bring
zcashd's wallet encryption (inherited from upstream) out of experimental feature mode. I’d rather get hardware wallet integration via some mechanism (or better support offline signing, something I’ve tried to implement several times).
In mobile environments that have much better environmental controls, there’s more we can do. If I were designing a mobile wallet from scratch, I’d encrypt the mnemonic phrase with age (or rage, which I’m the author of), using an identity stored in the OS’s keystore, and derive the actual spending keys on-the-fly. That would make it possible to authorize spends via the OS’s biometric authentication mechanism, with a fallback to only allowing that specific app to access the mnemonic (if I recall keystore semantics properly).
 The reason we made it experimental before launch back in 2016 is that it targets the second option (only spending keys are encrypted), and for Sprout there was no way to provide full viewing capabilities without the spending key. This would have caused the wallet to report an inflated balance, which is the absolute wrong thing to do. We fixed this for Sapling, but the above points remain valid.