I've been involved with open source projects for over a decade, so know this issue well.

Usually, if you dig in, there's a reason why some patch is left in limbo. These issues are sometimes not what you want to hear: it's buggy, it's not obviously buggy but seems "risky" and maybe not worth the cost, it solves an issue in a short term way but a long term solution is wanted, etc.

For a lot of these patches, when I dig in, the issue seems like one of those. For instance "re-issue getblocks to the next available peer when one disappears" got superseded by some other patch, and rebroad then said that the other patch wasn't actually ready to be merged. So I can see why it might have got stuck.

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

Again, same thing for "dust limit and filtered addresses". If you know enough about Bitcoin to know what this is about, you don't need a GUI to set them. It's not something that regular users should be thinking about.

As pointed out, sometimes people will disagree on these sorts of things. That's open source - the solution is for you to fork the project and maintain your own version with these features merged in. If you aren't a developer, find someone who agrees with you who is, or pay someone to do it.  That's how open source has always worked. If you refuse to do it, then you're refusing the very nature of open source itself!