Yes, I think we all would like that. I have no idea what is going on with or what the current status is of stealth/privacy features development for BitShares (there seems to be some controversy / non-technical issues happening slowing progress down there). I'll just speak about it from a purely technical perspective based on what I know.

When we bring blinded balances in the mix, we need to be very careful with the design of time-locked savings to ensure that an operation (seemingly coming from the user with active authority) which appears to just keep their funds in their control does not actually re-encrypt things in a way to make the secrets necessary to unblind the balances inaccessible to the user. (This is not really an issue for checking balances, because if an attacker ever got authority to spend those they could just instantaneously steal them anyway.) In other words, we need to not only consider threats in which a hacker is trying to steal funds, but also threats in which a vindictive hacker simply destroys the user's funds because they cannot steal them. Short of some advanced cryptography that I am not aware of, the way to prevent against this threat in time-locked savings balances is to require any merging of existing blinded savings balance outputs, either to clean up balance object usage or to collect together enough funds to make a withdrawal of a desired amount either to checking or to a savings balance with another withdrawal delay (whether lower or higher), to be a reversible delayed action with the same delay requirements as a straightforward withdrawal of it to checking. In short, it is just trickier to work out the safe design of time-locked savings when blinded balances are involved compared to public balances. But it is absolutely doable, worth doing, and worth doing right.

There are other complications worth noting about blinding balances.

First, if you blind BTS balances that BTS will not contribute to your stake when voting on witnesses, committee members, and workers. (Side note: although not mentioned in the proposal in the OP, I assumed that all public BTS balances held in savings would add up along with the checking balance towards the account's BTS voting stake.) Having less BTS stake voting, since a lot of it would likely be hidden by users for the sake of their privacy, is not great for the network, but I'm not sure if there is any solution around that if users wish to truly and very securely hide the amount of their BTS holdings. I've previously thought about solutions that allow the user to expose some chosen amount of just their BTS balances to a trusted third party (acting as their proxy) who aggregates the BTS amounts revealed to them by various users before revealing that aggregate amount publicly to the network (the privacy comes from the hope that enough individuals will be revealing their BTS balances to this proxy so that they can hide in the crowd). However, this system also has its issues. First, it puts limitations on how quickly you can spend the BTS balances that you have chosen to reveal to the proxy because those blinded amounts need to be locked up for a period of time otherwise this mechanism can be used to falsify the amount of BTS someone has for voting. Second, although users wouldn't want the lock-up period to be too high (for liquidity/convenience reasons), having too small of a window could harm their privacy. If they are the only one to, for example, stop revealing their balance to a particular proxy during a particular lock-up period, then the public could look at the delta between the two consecutive lock-up periods of the aggregate amount exposed by the proxy in order to determine a likely good estimate for how much BTS that user had. So, all of this complication just to allow some blinded BTS balances to be counted in proxy votes may just end up being an illusion of privacy in practice, which means it very likely isn't worth developing.

Second, losing access to your memo key (which is needed to derive the secrets to unblind your balances) means you will lose access to all your blinded funds. It doesn't matter if the network recognizes that your account technically owns them if you have no way of generating the cryptographic proofs to actually spend them. This is what makes blinded balances so dangerous. It is imperative to have a robust memo key backup procedure (such that the current memo key and public blockchain state can derive all past memo keys of the account) so that users do not end up losing access to funds when they change their private keys and realize they lost backups of their old one. Always using deterministically generated keys from a brain key (and safely backing up that brain key) helps with this. But if your brain key is compromised (and you still recover your account using the recovery account feature), you will need to use a new brain key, which cannot itself generate the old keys. So it is desirable to still have a robust backup mechanism to encrypt the most recent memo private key of the account known to the user on the blockchain in a way that is accessible using the current private memo key.

Third, despite all these complications, I think the effort required to build out the features to allow blinded balances using CA held in both checking and savings of an account (and of course the ability to do blinded transfers to other accounts using CA) is still pretty reasonable, at least on the core level (more effort is required to bring it to the GUI). But this provides financial privacy in the form of hiding how much of which assets you possess and also hides the amount and asset type being transferred from one account to another. It does not, however, also hide the metadata of the sender and receiver accounts that made some transfer at a specific time; that would still be publicly visible. This may be acceptable financial privacy to many, but unacceptable to others. To do better (hiding the metadata as well) would require even more effort and sophisticated design (especially if you still want it to be reasonably safe and easy-to-use for regular users), including the use of slightly more sophisticated cryptography like RingCT which Monero is using (or actually I would expect to see an adaptation of RingCT to use CA yielding a "RingCA", which I believe should be doable but I haven't yet looked into the details of how RingCT work). One thing to keep in mind is that we don't have to choose between them. There are advantages (in terms of lower time delays and cost) to just using plain CA and not hiding the metadata if you don't really care about that. Then those who really want more privacy can use the RingCA-based features that further try to obfuscate metadata. Assuming regular RingCA can be made to work with existing CA balance outputs without unblinding the amount / asset type in the process (which I think it can, but I don't know for sure), then it makes sense to first build out the regular CA support (not bothering to hide metadata yet) and then later build out the more advanced privacy features on top that further obfuscate metadata.