I have to comment on this.
1. Often, there aren't really a lot of unknowns. There are lots of times where the programming task is something along the lines of "Put together a UI that looks like this and behaves like that, takes data from these places over here, and if the user hits the 'save' button shove that data back over here to save it." That entire task is well-defined and quite straightforward, and there should be very little unknown about how to do it.
That's all fine and good, but unless you are heavily indentured into the actual infrastructure of all the systems involved, you're still doing guess work.
'Put together a UI that looks like this and behaves like that'. Yea, so what tool are you using? The existing one? Well, it doesn't allow the buttons to be exactly where the user interface wants. You can't manually hack it. So we have to write a custom module for that. The save button is actually having to talk to a MSQL database over the firewall into a vendor turnkey server, so we have to open up firewalls, write a custom database connector for the MSQL database, and oh, wait, you said the filesystem is on NFS as well? Oh, apparently the background save data needs to be faster than NFS can provide, so we need some SAN local disk as well. Wait, you don't have that in the budget? We have to put it on existing NFS? But it won't be fast enough. Wait, it doesn't matter? Ok, whatever.
If you ever assume a project is 'straight forward and well defined', then you don't deserve to be a PM. It's never that simple. Ever. If you had any experience in the field, you'd know that by now.
2. Estimates provide valuable information to those deciding what to do next. If a developer estimates project A (worth $3 million) at 20 days, that's likely to be a better return on investment than project B (worth $4 million) estimated at 40 days. Somebody just looking at revenue would be more likely to pick project B, somebody looking at the revenue plus the estimate would pick project A.
Estimates appease the share holders and investors. They also help utilize personal hours on projects. Otherwise, there's no real point to them. And sadly, you are absolutely correct that projects utilize the lowest dollar. What they don't realize that a lot of times, PM's, like yourself, are providing them with cooked numbers, based on half-assed quotes, ideas, and expectations without any real input from IT professionals who know their business. You basically tell them exactly what you said. 'We want X'. Give us hours. You don't tell them the budget, or if you do, it's prior to any hardware or software or man-hours. So now the IT professionals have to fit the timetable into the pre-defined man hours. Then other times, the upper management already have promised a deadline on the project prior to getting even you, the PM, involved, so you're just trying to get the IT people to find some way to make the unrealistic time frame work. Feed your BS to someone who doesn't know it for what it is.
3. The procrastination argument is simply wrong. If a developer has estimated 20 business days to do something, he may scramble to get it done on days 18-25. If he's given no estimate, days 20-60 zoom right by and he still doesn't have it done, because he can just put it off until tomorrow.
Then you need to find better employees. When I give '20 business days' to do something, it is the estimate of 20 + 8 hour days. Not '20 days'. Based on your comment above, you equate 20 business days as 20 direct days. Well, I have news for you. IT professionals, like programmers, are doing more than project work. They can not, and will not, be applied 100% on a singular project. The only exception to this are hired consultants who are tasked with ONLY the project at hand. And they are paid hourly for that work, at a very costly sum. For salary employees, they have more than just your project work. They have to maintain EXISTING work, they have to constantly keep their skill set updated, they have to work on OTHER projects. They also have family to consider so those 'late night work sessions' that you require of them or think you'll get out of them? Yea, think again.
I delt with a PM like you who had it in their head that 20 work days meant 20 straight days (including weekend work). Even if it didn't include weekend work, it would be unacceptable. My time as a system engineer is frankly 10% learning, 50% upkeep (including user access, standard tickets, etc), and 40% projects. That 40% is split between 8 projects that I'm working on. So your 20 business days? Yea, for me, that goes out to 5-10% of my time a day, more when I need to balance priorities (if directed by management on what is the priority for the week). So at 1-2 hours a day, on your project, you do the math.
You want better time, you hire more people to do the job, which increases the budget. Management don't like that. So that's what causes IT professionals to work weekends. Because PM's like you pull figures out of the air, or management enforce figures that you are forced to stick to. Either way, estimates are crap.