I have used wire-frames (including annotations) successfully in many projects. Accompanied by other artifacts such as a site map, interaction (activity) diagrams, design rationale documentation and use case descriptions, they are very powerful tools for rapidly communicating, negotiating and agreeing upon requirements and the overall design during an application development project. The secret with wire-frames is to create them with the intended audience in mind.
I have also seen wire-frames being misused several times. The typical misuse is that an external design agency, which is typically responsible for the visual design and interaction design, uses wire-frames internally in their in-house design process. In that process, they do not involve external stakeholders such as content authors and the application development team that is to design and build the application. Instead, they deliver the wire-frames together with a site map, style guide and other artifacts as a part of their final delivery, naively expecting the receiving application development team and content authors to use them blueprints for building the applications and developing the content. The problem is only that it is not possible to implement them at a feasible cost and that they do not fulfill the content requirements. So the design agency is forced to return to the drawing table, annoyed by all the "criticism" (feedback) that "questioned" (provided input to) their design solutions. At this point they should realize that they need to open up a dialog with external stakeholders, but they probably won’t.
Properly used, wire-frames provide a language which all parties in a development project can understand and talk and a vehicle for messages at the same time. IT people, user experience designers and content authors get a means to talk with and understand each other. If wireframes are used as collaboration tools in a dialog with designers from the other design disciplines, wire-frames will serve as the lingua franca in application development.