Any policy must have a reason and must be communicated to the team that these policies apply. It would be highly desirable that the team agrees with the policy or at least doesn't feel uncomfortable being ruled by it, what is easier is if the policy is properly communicated including reasons and benefits. It's some kind of virtuous cycle.
Related to that, @Mark C. Wallace has made very good points about how this feature is used and understood by the team. Internally, it has shown to be useful.
The problem with this kind of policy in the way it is implemented by MS Exchange, is that it is not possible to differentiate between mails sent internally to a team, inside the company, and to external customers or providers. Given that the original question was about use of this setting for "all" emails, I must answer no. I would instead use it in a more limited environment and building on top of other answers given in the thread combine it with "Request Delivery Receipt" as it better serves you.
My personal experience, is that the problem of using this "Read Receipt" comes from misuse. It is understood that if a "Read receipt" is received, what could have been sent automatically as has also been said, the message has been fully read, understood (as it was mean to be understood, extra point) and agreed to any points included what doesn´t need to be the case as the receiver have not even the time to read the mail (for a variety of reasons). And the top problem I have found is that some bully coworkers understand that there are SLA's that apply to mail response (sometimes the time starting even before you open the mail).
As an additional alternatives to the ones provided, in my team, we add to the subject some "tags" to identify the email, easing sorting and clarifying what kind of email is and what is expected:(info)(urgent)(ActReq)(customer1)(project2) are combined so that only the necessary people hurry up to read and reply to the email while the rest will read it when the rest of their tasks permits. And then, the cherry of the cake is to use properly To: and Cc:(Bcc:).
In summary, the "read receipt" is a good idea if used properly, but the implementation doesn't help to make a good use of it.