Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates.
I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them.
And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.