I’d say it’s more about having the right process.
You’re right that a process that demands you create wireframes or work in sprints is too granular to be effective. You’d end up doing a lot of work that adds little or no value just to check a box.
Going back to your carpentry example, building a deck and remodeling a bathroom are different problems that require different tasks to solve, but still have a lot in common. In both cases, the carpenter would do well to ask some questions of their client. How will they use that deck? Do they plan to entertain large groups? How much work are they willing to put into maintenance? Why are they redesigning the bathroom? Is it just a style update or is there a functional change they want to make, like replacing the tub with a walk-in shower? What’s their budget?
Does the carpenter then jump right to building that deck/bathroom or do they include some step to make sure it’s what their client wants? Do they show them material samples? Render it in a 3d program? They may have learned the hard way it’s easier, cheaper and more agreeable to change the tile in a render rather than after it’s on the wall.
They probably need to get the necessary permits. When do they do that? I’d think it’s safe to say it should happen before construction starts.
A good process is what makes success repeatable. A process that treats every problem like a nail so you can hit it with the same hammer isn’t a good process.