So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
If you intend to the issues up when you reach another state (e.g. widely usable) then indicating that the not accepting issues is a temporary state would be good. I completely understand not wanting issues raised when you already have dozens of things that you know that you need to do already.
From a user point of view the issues list is something I often look at before even using a project to see the activity, scale of the current problems people are having. I also find it a useful source of answers/workarounds. That doesn't mean that you can't be decisive about what issues you choose to work on (from a user perspective a clear response of "no time to work on this issue, send a PR if you sort it" is better than silence).
No one is entitled to anything with open source, not even support or a bug tracker. The author is trying to provide an open source alternative to a closed source product controlled by an uncommunicative company. He deserves support and help, not people telling him what to do.