They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the real value lies. Someone says "3 points", and someone points out they haven't thought about how it will require X, Y, and Z. Someone else says "40 points" and they're asked to explain and it turns out they misunderstood the feature entirely. After somewhere from 2 to 20 minutes, everyone has tried to think about all the gotchas and all the ways it might be done more easily, and you come up with an estimate. History tells you how many points you usually deliver per sprint, and after a few months the team usually gets pretty accurate to within +/- 10% or so, since underestimation on one story gets balanced by overestimation on another.
It's not magic. It prevents you from estimating things longer than a sprint, because it assumes that's impossible. But it does ensure that you're constantly delivering value at a steady pace, and that you revisit the cost/benefit tradeoff of each new piece of work at every sprint, so you're not blindsided by everything being 10x or 20x slower than expected after 3 or 6 months.
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
But neither case requires too much thought or discussion. My point was more that estimation ends up overwhelming time and energy, when you can just do the thing instead. I've worked on teams where we've spent more time arguing about how complex a task than it would've been for someone to crank out a solution.
I also don't mean engineers shouldn't collaborate, just that it should be more ad-hoc and not manager/tpm/scrum-master driven.