Ease of bug reporting == caring for the project?
Seems like Padre (the Perl IDE, ya know...) got some heat for using a Trac bug tracking system instead of the default CPAN RT system.
Dancer, as mentioned in Gabor's post, prefers to use the Github Issues ticket system to keep track of bugs, wishes, expected features, etc.
I agree there's a certain barrier to provide bugs for Padre and Dancer or any other project that uses a non-CPAN-RT ticket system. I personally hate registering for websites and have decided not to file a bug more than once because I had to register. (case in point: notifying Yahoo! someone is abusing their mailing list system for SPAM.)
On the other hand, being able to keep your tickets where you keep your code (or in Padre's case, where you keep your website and resources) has it's benefits. Although I use RT for many of my modules (or modules I work along with), and I'm thankful for having RT for free, I still like the option of using the Github I have for keeping score and I personally use it (though I accept RT tickets just the same).
I reckon it's close to (if not the same as) the discussion I started on whether your project's CPAN page is the same as a homepage, and whether it is suffice to provide an image for your project. My opinion remains the same: "it's really awesome to have it, but it can't be all." That has also been the vast opinion in Dancer, which has a (hopefully) extensive POD in CPAN, but also a website as a beautiful interface to the project for all users (Perlers and non-Perlers). I was quite glad when I saw Padre have an independent website.
Sometimes we can't see the benefits a project developer's decision has over our preferences and we assume that our preferences are more important. They aren't. Sometimes a project developer makes a decision that seems yucky at first but has overall gains. If there were no gains in Padre using Trac, they wouldn't. If we at Dancer didn't have benefits for using Github Issues, we wouldn't use it either. None of us are this stupid.
So, there is a great deal of "caring" in these decisions. Sometimes there's a disadvantage such as a disgruntled user or developer that decides "bahh! I won't provide this project my incredible bug report!" (and that's fine, I've had my share of those myself) and sometimes there are advantages such as being able to provide users with a common, consolidated interface for everything about Padre and not "wait, now we're going to CPAN? Now RT? Now what? Oh, this is the help manual at perlide.org? What's this now?". (imagine last sentence done in a heavy British accent, it will be funnier this way, I promise :)
(Of course, I'm assuming on why Padre prefer Trac. They probably have other (and perhaps better) reasons than what I just jotted down.)
In conclusion, you don't like it? Oh well, it's your right. But don't assume that just because you would have made a different decision, they should too. They might see/know some stuff you don't.
When you are dealing with good projects, and Padre undoubtedly is a good project, reporting bugs through some bug tracking tool is the last resort. With Padre, e.g., you can simply dump your complaints in their IRC channel and they will try to help you before you have to go and register something, that might already be fixed in trunk or which might be a user error or whatever.
What I am trying to say is: Making it easier for users to communicate with the developers is the hallmark of a good project. And bug tracking, sadly (?), is very far from communication.
I think Gabor covered the issue pretty clearly in the post you linked: It's trivially true that if you don't care about your users you shouldn't release your software. The problematic part of the complaint he received is the assertion that making bug reporting easy to use is equivalent to caring about your users.
Gist of the rebuttal to that is simply: Ease of bug reporting is not the whole picture. The most important part of caring about your users is providing them with useful software. Communication and bug reporting are means to that end. To wit, if you provide an easy-to-use bug reporting mechanism but you aren't able to fix the bugs that are reported (because of duplicates or noise or difficulty of integration with your repo, whatever) then you haven't improved your software, which was the whole point to begin with.