You can say "Reported Customer Issue" or anything else if it makes people happy. I'm going to say "Bug" because it has such a grand history and is the industry standard term. In a brand new bug list, you might expect to fix near 100%. But the more bugs that are added to the list, the fewer you expect to fix. In fact, most bug tracking tools let you close bugs for various reasons: duplicate, feature-request, unable-to-reproduce, on-hold, additional-feedback-needed, etc.
The important thing is to capture the feedback and the actions taken on that feedback. We make it very clear to our customers that we get to choose what bugs we fix and what features we implement. We do it on the basis of what we think will make the most clients most happy, but it's our choice.
Be respectful in providing feedback on these bugs. If you aren't going to fix something, tell them why. Sometimes it's OK to say that you aren't ready to commit to a particular solution to a given bug. Or that a bug is out of scope for this release (or this product). Or that a bug in how the system works might be "fixed" through improved documentation (such as tweaking the UI or documentation so that users don't do what caused the bug). Obviously, if you fix some bugs, your client will be more open to your not fixing others.
If the customer has major problems using your software, no bug naming system will make them happy. If they love your software, the name won't matter either. Make great software, be respectful to your client and don't get hung up on bug categories.
Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?
You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can.
If you never reproduced the bug and saw it for yourself, how can you be 100% certain that you really fixed it? Maybe your proposed fix introduces some other subtle bug that won't manifest unless you actually try to reproduce the original defect.
If I am a senior developer, should I be able to read (multithreaded) code and create a mental picture of what it does in all use case scenarios rather than require to run the application, test different use case scenarios hands on, and step through the code line by line? Or am I a poor developer for demanding that kind of work environment? Is debugging for sissies?
I would not trust someone who runs the code "in their head", if that's their only approach. It's a good place to start. Reproducing the bug, and fixing it and then demonstrating that the solution prevents the bug from reoccurring - that is where it should end.
How should I talk with my team to convince them that my approach is reasonable, conservative and more bulletproof?
Because if they never reproduced the bug, they can't know for certain that it is fixed. And if the customer comes back and complains that the bug is still there, that is not a Good Thing. After all, they are paying you big $$$ (I assume) to deal with this problem.
If you fail to fix the problem properly, you've broken faith with the customer (to some degree) and if there are competitors in your market, they may not remain your customer.
Best Answer
First of all, if you aren't yet using an issue tracker tool, get one and make it accessible to users. This way they can enter their bugs into it, rather than pestering you directly via emails or phone calls. You should of course train them to use the tool correctly - this may be a significant initial investment, but it will quickly pay off.
Let users freely report anything they consider a bug, but have them assign severity and/or priority to each bug. This allows you to focus on the most important / urgent ones, but still keep track of all. All decent bug trackers have built in support for these properties, and allow you to query / filter / order bugs according to them. In case the severity or priority of a bug is incorrect, you can discuss this with the user and modify it. If some users often report issues which aren't real bugs, or aren't reproduceable, you (or your management) may need to discuss this with them, and/or - again - educate them on how to document items to make them usable in the development process.