This is the standard answer when developers don't think they will get around to doing something in any reasonable timeframe, but it's been repeatedly brought up.
It's most unfair when it's been repeatedly brought up, but the person who's most recently mentioned it doesn't know that, and just gets "we are taking patches for that" right away. In this case the maintainer is fed up with the discussion but the user thinks it's a new topic. Anyhow, most likely if you get "taking patches" right away, you shouldn't take it personally but might want to read over the archives and bug tracker for more details on the issue.
If you are repeatedly bringing up a request yourself, "taking patches" is potentially intended to be a relatively polite brush-off, vs. some less polite alternatives...
And then of course there are rude maintainers who will say "taking patches" with no explanation ever to anyone, but I'd say that's a minority.
If you've ever maintained an open source project with a lot of users, you'll know that there are 100x more requests than the maintainers could ever get to, and many of those requests are important to the requester but would be outrageously difficult, or would disrupt a lot of other users, or have some other flaw that's only visible with a global understanding of the project and codebase. Or sometimes there are just judgment calls, and it takes too much time to argue every one over and over.
Most non-open-source companies will not give you access to the developers at all, and you'll just get the silent treatment or a polite but bogus story from customer support. So, in open source at least you have some options (pay someone to code the feature, etc.) and while developers might be rude, at least they give straight answers. I'd rather have "no" than the usual "it's on our roadmap... [2 years later] ... it's still on our roadmap" kind of thing I've gotten from a number of vendors...
So I don't think there's a retort. Maybe the open source maintainer is just really busy, maybe they're a jerk, but either way, they likely have a tough job and getting into a who-has-the-last-word debate isn't going anywhere. The best you can do is contribute in some way and try to be constructive.
Maybe it isn't code, but possibly there's a lot of analysis and documenting user scenarios you could do. When I was maintaining the GNOME window manager, lots of times it would have been helpful for people to go analyze a problem globally considering all users, and really write down the issues and pros and cons and what should happen from a global perspective.
(Instead, the usual thing was to start flaming as if they were the only user that mattered and there were no tradeoffs. And while that's great, and was a datapoint, and often I managed to stay polite or even solve their problem eventually... flaming does not make anything happen more quickly. It just confuses emotions into the issue and wastes everyone's time.)