Programming is complex. Stop for a minute and imagine how complex it is. No, it's ten times as complex as that. No, you just underestimated it again, it's another ten times more complex than that! Every feature adds complexity and can cause unforeseen interactions and side-effects, some of which are bugs (some are happy accidents).
Why would a programmer "hope" a bug has been fixed? Because they don't have the time or the domain knowledge to be more certain. Any programmer who tells you there is a 100% chance that a particular bug is fixed is lying. There is always a degree of uncertainty, and a good programmer will be honest about this uncertainty. This doesn't mean that they're not doing their jobs properly! Their manager might demand a quick turnaround on bug fixing, so they can work on "higher priority" stuff. They might need more time to become familiar with the software or the domain, anywhere from hours to months.
Some production bugs are really hard to reproduce in a development or testing environment. In this case, you (the programmers and/or testers) either spend more time investigating, or "hope" that you can fix the production error without reproducing it. There needs to be a clear sense of ROI: Return On Investment (of time).
Who should spend the time understanding the bug? It's the testers' responsibility to provide clear steps to reproduce the bug. If it's an intermittent bug, they should say how often it occurs. It is not the testers' responsibility to diagnose the cause or pinpoint a line of code causing the bug, although a comment like "this only seems to happen between 11:00 am and midday" can very useful if it helps narrow down where the root cause of the bug lies. I have found that testers often get this root cause analysis wrong, because it's not the part of the project they work with every day. This is not to say that the testers should have no input into the programmers' work, or that programmers should have no opinion on UI, etc., only that they aren't the ones who have the responsibility to make decisions in other people's areas, they can only advise and their advice can be overruled by other concerns. Testers shouldn't try to be expert programmers and programmers shouldn't try to be expert testers, or decide which bugs are "important" and which aren't. Both programmers and testers should work together since they have a common goal: releasing a product that's fit for purpose.
Once the conditions to trigger the bug are known, it's the programmers' responsibility to track down the root cause, fix it, make the fix ready for testing and notify the testers. There is a clear line of division of responsibility. Programmers are responsible for writing maintainable code that is fit for purpose. Testers are responsible for verifying the programmers' code, including exploring edge cases that the programmers haven't thought of. The whole team (including programmers and testers) is responsible for delivering a working product.
What the programmers shouldn't do is make a token change without trying to understand the root cause and "throw it over the fence" for the testers to verify. That is indeed disrespectful. The programmers and testers need to be equally respectful of each other's time. Management plays a part in this too. Some teams are in a high pressure environment where they try to blame others for their lack of time when it's their managers setting unrealistic expectations. It's easy to judge someone else's behaviour without trying to understand it first. I always try to make sure everybody in a discussion is on the same page before trying to move forward.
Importantly, every change, big and small needs to be tested, because you have no idea what it could have accidentally broken without fully (re)testing it. Hopefully, you have automated tests that do the bulk of your testing. Programmers should have a suite of unit tests, QA should have a suite of acceptance tests. Each step should be sanity checked as well. New bugs should have tests written for them and included in the testing suite.
Lastly, if the bug is gone, it shouldn't be rejected. The programmers made some changes to make the bug disappear, therefore the bug is "fixed" not "rejected". A bug should only be rejected if it turns out it was incorrectly reported, or can't be reproduced in any environment, including production. Sometimes bug can be closed as "won't fix", i.e. it's either not considered a bug or it's not considered worth fixing.