A good writer is one who pays equal weightage to proof reading or editing of his work besides being focussed on content quality and writing style. For every new work that a good writer produces, he doesn’t mind spending some more time on it and getting some different opinion on what he has written. The great author Hemingway always had his books edited and proofread before giving it a final nod for publishing.
Similar approach must be inculcated in a tester too as far as bug reporting is concerned. The way a bug is reported may not be understood or interpreted in the same manner by a different set of eyes reading it with a different frame of mind.
In bug report, a tester knows clearly what is intended to be reported from his end. He might explain about a bug thinking it as the best way to communicate his purpose. A developer on the other hand as a different entity may understand differently to what tester intended to communicate and thus may take a different meaning that may lead bug fixing to a different direction.
Definitely in case of a doubt, when developer seeks clarification from tester about a bug, things would get clearer removing out all gaps in intention of report and its understanding. Bug reporting is always an interactive process. Logically after reporting a bug a tester must leave report as it is without sending it to development team. After sometime tester must come back on the same report that he left, read it as a developer would read it. This way of editing with a virtual different pair of eyes a tester would be able to seal any leaks in his bug report.
Rereading and editing of report is in no way a waste of time or effort comparing it with the time or efforts required later in wake of unclearly reported bugs. In a broader way, it can be treated as a quality check of bug report.