I saw your text as a light grey so I decided to re-read it a few times. I absolutely agree with you. The people who complain the least should be paid the most attention when they do.
There is a lecture by the late Randy Pausch (https://www.youtube.com/watch?v=ji5_MqicxSo&vl=en). The gist of the part I'm mentioning is, "When I stop correcting you, I've given up on you." People who don't voice their opinions aren't necessarily happy, they quite possibly have decided it's not worth trying to change things.
Yes, I think promoting people who DO NOT complain is problematic.
There is no right way to deal with this other than to listen to complains and figure out what it is.
One way of thinking about complaining is that it is a form of feedback. As a manager, you don't want to silence people giving you feedback, frankly, this is about as stupid thing as you can do.
Better way to deal with complaints is to educate on what kind of complaints are productive and what kinds are destructive.
For example, I try (not always succeed) to restrict to myself to only complain about things that I am ready to solve if somebody tells me "go ahead, fix it".
Funny how this can reinforce the idea that only incompetent people complain.
Imagine a situation where the company and/or the project have a few serious problems, but the company refuses to fix or even admit any of that. The developers who couldn't live with the problems have already quit. The developers who remained have stopped complaining, because they have given up.
A new developer comes, notices the problems, and starts complaining about them. People notice that the newbie makes a fuss, but nothing changes. Later the developer either quits, or gets used to it and stops complaining.
Here is how the management probably interprets the situation: "People with the least experience complain most. The correct approach is to ignore them, and wait for them to grow up. More experienced developers have realistic expectations and mature behavior."
If no developer complained about anything nothing would change and the project would be slippery slope to oblivion.
Usually any project needs some kind of feedback loop to correct any problems and most of the time an important link in the loop is developers complaining.
It just needs to be done in a productive way. For example, retrospective is an attempt to direct complaining to be productive element in the process.
Also, it is a good starting point to be very cautious abut any radical opinions like that.