Ouch, couple of topics here.

First, the issue with ninjamine was that it could be (and ultimately was) used for governance. Now that it is in DHF, the funds can actually be used the way the community thought they should be used (they are mostly not used that way currently, but that is separate issue).

DHF currently still has over 37M HIVE from ninjamine. It converts that HIVE to HBD at a rate of HIVE_PROPOSAL_CONVERSION_RATE (5 basis points) per day, which means ~18800 HIVE (about 6000 HBD extra). Example block containing such dhf_conversion_operation.
Compared to funding it receives from inflation, that is significant amount. DHF receives database_api::get_dynamic_global_properties().proposal_fund_percent, which is HIVE_PROPOSAL_FUND_PERCENT_HF21 (10 percent) of inflation. It receives new funds every block, but since payouts are once per hour, the new funds are recorded once per hour as well, indicated by dhf_funding_operation. Currently it amounts to around 3000 HBD per day. It means ninjamine conversions are responsible for 2/3 of new funds in DHF.
Total potential payout output does not depend on new funds though, that would be true if fund was dry. It depends on current amount of HBD on balance, which is over 23M at the moment. Daily output limit is 1 percent of that (I just noticed a small problem - the value is not defined where it should, that is, in config.hpp, but in some local constant dhf_processor::total_amount_divider). Cut that by 24 and get actual hourly payout limit. New funds are responsible for completely insignificant portion of potential payout. Return proposal, even in normal situation, has more impact on future size of pool than new funds, inflation or ninjamine.

Voting for proposals has some inertia. Voters would need to use bots to constantly monitor votes of others and adjust their vote based on what proposals they vote for went below return proposal (and then such bots would end up constantly adjusting votes spamming the network :o) ). Three top voters for return proposal could drop their vote to counter most of influence of blocktrades. Complete counter would require more vote changes, true, but it is not like it couldn't be done. Of course, I don't even know why such move was made, maybe whales are in agreement there.

Finally there is also the issue of how DHF funding affects funded projects. The way it currently works is only suitable for infrastructure - when it fails to get the funding, you can just stop renting the server and some Hive API nodes disappear from the network. Once funding is back it only requires at most couple days to set it up again. But there are projects that need one time all-or-nothing funding (f.e. some promotional event or a simple app/bot script). The thing that should be the main focus of DHF - development - requires continuous and secure funding, especially for bigger projects with multiple people involved. Even if you have a team that is also doing other work, switching people between projects generates a lot of friction. Also you might end up having a lot of work wasted, because it is really hard to pick up development of the feature that was only partially implemented, even for the same developer, after some time passed (and partially implemented feature might even have negative value for Hive, because it might make it harder to do other changes).
Allowing downvotes for proposals seems like a good start, but much more comprehensive changes are needed. I don't have any good ideas though :o)