Mechanics don't use time + material. They use a book that states "for this car to do this thing, charge this many hours labor." If the book says 4 hours and it takes them 3 hours you pay for 4 hours. They can tell you with a high level of certainty exactly what your bill will be for that service. However, that's irrelevant because it's a false analogy to compare that to building custom software.

The correct analogy would be asking someone to build you a custom car. Sure, some things MAY be standard. "We plan to use off the shelf components for the brakes. Those cost this much to purchase and install on the given frame."

"Plan" is the operative term there. As the custom car project continues, you decide that you want more braking power or there are conflicts between the chosen brake components and other custom components you specified and they need to remove the brakes and replace them with something else. I'd encourage you to spend time around a hotrod shop.

The reason "getting better at estimation" isn't something professional software engineers should focus on is that it just costs money doing an activity that doesn't add any value to the end user. It's simply theater.

Yes, I've been trained and have tried to use many different estimation practices over the past 30 years. They are all perfectly good for things like building houses, just not custom houses.

Break things down small, deliver them, focus on feedback, and stop delivering when the needs are met.