There are a few issues. First, using old anchors demonstrates that the source of funds from the transaction is no more recent than the chosen anchor. Second, the fact that the wallet is choosing an old anchor can reveal which wallet is being used, as most of the wallets I’m aware of require recent anchors. Finally, depending upon sync behavior, one can infer the time at which the user last synced their wallet. None of these are individually identifying, but it’s still a lot of information to leak to all observers of the chain. Now, for a lot of users, this level of leakage might not matter, but for users who are being specifically targeted (particularly if their counterparties are malicious and/or they’ve been sent notes at known heights with the intent of using this leaked information to help deanonymize them), it could be a problem.
With respect to your second question, yes, absolutely. Also, once a subtree has been fully scanned, there’s no need to perform any redundant work - at that point, all of the notes in that subtree can be made immediately spendable with O(1) work, and it’s only notes in subtrees that were incomplete at the time of the last wallet sync where it may be necessary to wait for tree updates.
Using a system of bridges provided by the lightwallet server as @hanh suggests can make the latter also a non-issue. Discovery of new notes is always going to be the thing that takes longer, absent detection keys or liberated payments, but as @hanh says at the current post-sandblasting level of chain usage, this isn’t really a bottleneck either. In the ECC SDK we need to change the scanning strategy to use adaptive block range sizing based upon how full blocks are; that was something that we wanted for the original 2.0 release but didn’t have time to implement, and that will also help.