There are tradeoffs here.
All of these deterministic wallets are based on schemes I originally promoted in one form or another, so I'm certainly no enemy to them. I mounted an unsuccessful effort in early 2011 to get buy in for changing. A lot of people were— and some still are— suspicious about deterministic schemes.
At the same time, key management is an essential part of the safe use of cryptographic systems. Losing control of an old system or an old backup— say, after it ends up on ebay— should not result in you losing funds, and certainly not all your funds. The use of non-deterministic keys automatically has some good key management properties. The problem is that it doesn't mesh well with backups. Swinging 100% the other way to deterministic keys does well with backups, but so far the implementations I've seen have completely neglected key management. They effectively put all the eggs in one basket, which isn't good— especially systems which use the type-2 homomorphism exclusively as compromise of a single key potentially compromises all of them.
As with most things in engineering a middle path is probably best.... as also with most things in engineering, the first try is seldom the best.
In Bitcoin-Qt you can adjust the keypool size to better match your usage and backup patterns. This is— in my opinion— too much to ask of many users, so I'm not defending it as a good setup, but it's perhaps not quite as bad as you're thinking.
In my opinion an ideal system would support multiple independent master keys, precomputing the next one, and doing controlled transactions triggered by backups, according to user configurable retention policies... e.g. An example policy: once a month it adds a new master key which is initially unused, then after at least one month and four backups have passed it switches to using it (so the key has made it into at least four backups), funds which remain on keys which are over a year old are periodically swept onto new keys. I think an ideal system would would also include things like an emergency key compromise panic buttons which would generate new keys, walk you through creating a new set of backups, and then migrate all the funds.
Deterministic key generation schemes that overcome this problem were designed long ago and exist in many alternate implementations e.g. Armory, Electrum .... and BOP.
[...]
You seem to recognize why there is a market
Yes, invented
long ago by the Bitcoin core development team, and eagerly rushed to market by alternative implementations — potentially heedless of security considerations, design fragility, quality of specification, full spectrum of use cases, performance, implications of key management, compatibility, etc.
I'm super happy that people went out and built new and interesting things— and I intentionally decided to allow the patentablity window on the homorphic derivation scheme to close, because I concluded that paranoia over the patent would to more harm than the good that could be done by defensive licensing.
Your own software implements
BIP32 as well, now— and while I cannot say you rushed... but please, if you're going to brag about some feature you have that Bitcoin-QT lacks, please don't pick one that Bitcoin-QT lacks because instead we were spending time building the feature for everyone else— including you— too. Your patches are welcome to Bitcoin-QT as well. Or does the collaboration only flow in one direction?
