It's possible to remove the default route for the other ISP if it's broken, or to add more specifics to point to the working ISP if necessary.
Exactly. And the easiest way to do so is to have full route.
If you are not convinced, here is a reality check.
How many of multihomed (non-transit) entities today are using the default-only approach?
Uhh, quite many? There are a lot more ways to "multihome" than just getting an AS, prefix, and BGP feed from two ISPs. I think many actually use solutions like FatPipe WARP (http://www.fatpipeinc.com/), or LinkProof to get a subset of multihoming benefits.
Perhaps there is a partial mismatch of assumptions.
For me, the home or small office users could want to start want multihoming too. For them, BGP-like mechanisms and full routing tables seem like an overkill. For midsize enterprises I would like to say the same, unless they insist otherwise. For really big enterprises, it seems fighting against them seems like a battle against the windmill.
What we need is a set of rather simple and workable multihoming procedures which don't need (global) routing protocols, public AS numbers or provider independent addresses. But that procedure need not be exclusive, "the only way". For e.g. bigger organizations, there could be different methods.
Maybe you're mostly concerned on those (big) folks who multihome today, with known mechanisms.
Maybe multiaddressing fits to some of their objectives, maybe not. But even if it does, they should be able to handle a pretty large routing table because .. well.. they already do it today.