In any case, the real fact is that not that many people are willing to do the tradeoff of memory vs battery life. As a software developer, I consider myself to be a power user as well, but the times I *really* need more than 16GB are extremely rare. In 99% of occasions, I get by just fine with 16GB.
Most of the time, I'm looking at a code editor, editing code. Occasionally compiling and linking that code. For my usage situation, going to 32GB of DDR4 with the tradeoff in battery life just would not be worth it. And I suppose that would be the same for at least 90% of other "professionals" out there. To add another vector of internal design, battery layout etc, to cater for that 10% market, would not make any sense for Apple.
32GB RAM for some database work btw, are you loading the whole database into RAM at once? Why would you do such a thing?
out database platform is extreme IO limited and bound. There are many routines I need to do for DB maintenance that can benefit from loading large portions of it into RAM. For example, if I want to do table moves from database extent to database extent, doing so directly on Disk can be quite time consuming. A trick I've learned is to ready everything into RAM, perform my DB operations within RAM, then write to disk, to prevent simultaneous read and write IO.
using this method i've managed to get some of my routines down from hours to minutes.