_ testing / evaluating / repairing older systems;
_ refurbishing older systems (e.g. for donation);
I do both, and stand by my comment about RAM in this context. Specifically with regard to refurbishing older systems, I wouldn't claim to have refurbished an older system if I hadn't made sure it had at least enough RAM to run a lightweight desktop, which seems to imply at least 512MB nowadays. In fact, I'd be embarrassed to deliver a system with less than 1GB and call it "refurbished".
_ testing UBCD in VMs (which means that less than half of the host's RAM is available).
Not sure I understand why you'd do this on such a low end machine, since with virtualization you can set the specs you want regardless of the host, but OK.
In other words, new systems in 1st-world countries are not the only "typical use" of UBCD.
I'm not thinking only of new systems, but it's true that my personal experience is limited to 1st-world countries.
Independently, UBCD should always try to use as minimal resources as possible, perhaps with alternative (not default) options for taking advantage of more resources when they are available.
Trying to use minimal resources is a valid goal, as is trying to take advantage of new norms. Trying to do both in one package adds complexity. Since I'm not involved in developing UBCD, I won't try to evaluate whether that's worthwhile.
I'm not saying anything is wrong with the way it is now, just offering my viewpoint.