You could contact the dev and have a discussion with him! If the dev doesn't want it to be a feature in his software, you can post your changes as a plugin/add-on. Effort spent on improving a software rarely goes wasted.
Rarely wasted? Have you seen how many open issues and pull requests on github just languish there forever by unconcerned maintainers? Or projects with a million forks because the maintainer has moved on?
Stating up front that you're not going to even entertain bug reports definitely has an impact on those wishing to improve the software and contribute back. For one, it precludes an entire class of supporters (users who report bugs) from even helping out at all.
So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
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.
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).
Or are you volunteering to do the bug triage part?