I know this is easier to say to some people than others. If working on an agile team, you have no problem with this.
There does come a point where you can stop and leave the sketches behind. Maybe you can use them as a reference to remind yourself what you were thinking. But you don't necessarily need to rework or update them—and the same with wireframes—the purpose of them is to help you think, make decisions, and pick the solution you're going to design. Then you build.
The problem I have selling this idea is that for a lot of people, especially in in the agency scenario, the document is the deliverable they're selling. In an agile team you would have no problem with this since many product teams start their working code.
This goes along with the discussion over documentation argument. If the situation allows, you build when the expression of the interface is good enough that everyone understand what to build. Then that expression gets validated or disproved with a working product.
If you’ve done you’re work of picking the right design, and solving the right problem, then the risk has already been mitigated in a huge way, so you hopefully need only to make smaller changes rather than disruptive pivots.