Why is it of any importance how I communicate in my role as a tester?

I just publish the latest defect I found and its off for fixing or rejection ... ???

It is my belief that the first and foremost important mission for us testers is providing information to the project.
This information will contain details such as, what defects we found, what potential threats and risks we see, how much of the product have we covered with our testing and a number other factors.
If we do this with confidence and integrity we may even over time gain the status of "trusted advisor" to the project leader, but in order for us to achieve that it is a requirement (among others) that we have the skills necessary to communicate our message.

Coming into the office of the project leader screaming and shouting about the latest defect that got rejected at the review board will most often not get us much and it will definitely not work in our favor in the long run.

Communcation skills (or even Social skills) is not limited to verbal communication face to face but also communication through different mediums such as email, telephone etc.
All different forms of communication has its own strengths and weaknesses and it is important to choose the one suitable for the current context.

Sometimes it will be necessary walk over to the developer and sweet talk him into looking at your defect and giving it a second thought.
Other times you might have to email the developer and also cc her team leader for that extra punch (don't misuse this though ...)
Other times yet speed will be of the essence and you just have to pick up the phone and talk to the project leader for escalation of your defect (it can be a show-stopper after all).

All these examples call for different kinds of communication and it is up to you to be able to master them all.

When posting a defect it represents different things for different stakeholders.
The project leader might see a risk in delaying the project, the developer might see critique of his or her code (aka. their "baby").
Just simply posting the defect will not do.
We must first document and post the defect in a clear manner that is easily understood by different parties.
It must be general enough for non-developer to estimate its severeness.
It must also be technical enough for the developer to easily dig into it and reproduce it.

After this the defect might come into question in the review board and we might have to either defend it ourselfs in front of the board or we might have had to prepare our test lead with the necessary details so they can do that on our behalf.

Finally the developer might question our defect (when has that ever happened?) and we will have to walk over there and discuss it with them.

All this above is part of something called "bug advocacy" ("Lessons learned in Software Testing", Kaner/Bach/Petichord) and its a vital skill for all testers in my opinion and is helped by good communication skills.

To summarize I beleive it is our duty for the project and the stakeholders to learn how to communicate our message or we will not be doing our job to our fullest potential.