That's fine if you:

• Never upgrade your tech stack.

• Always use people of exactly the same level of skill.

• Assume the project stops at implementing a static set of requirements given up front.

• Assume the requirements are correct.

• Assume there's no political dimension to the actual deployment and usage of the app, i.e. the project is just software and not a business change project.

In practice none of these things are ever true. The business doesn't want a CRUD app, it wants an automated process that it probably can't explain, will change half way through the implementation and some of the employees may resist deployment of the software. And people expect software development to get cheaper and faster over time, as with everything else in life, so you can't exactly ship a Visual Basic 6 app in 2018 because that's what you happen to know best so you can easily estimate work with it.

I've been developing CRUD apps for my company's clients for eight years. They're all superficially the same, but every single one of them has had something unique about their schema design, and they all have different business rules (in a general sense and in specific details) that make every project unique. We have a model that gives us ballpark estimates before we get into detailed analysis, but every time a customer insists on taking our ballpark estimate and treating it as a fixed-price commitment, the project becomes uncomfortably stressful.

I was just talking to a dirt moving contractor, he would say essentially the same thing as you.

Estimate higher then.

If I am developing a standard project, I will give you accurate estimates that are often correct. If I am building a custom project, my estimates will vary greatly, based on how custom it is, how well you describe what you want, and how many times I can expect you to change your mind about something.

It's really easy to tell whether you're building something standard. If it is standard, you don't need to write software for it. Say you want a standard blog. You use Wordpress. Say you want a blog that's kind of like Wordpress but a little bit different. You need to hire a programmer to write a custom component.

Effectively, all the software we write is custom. Once something becomes standardized, you no longer "build" that software. If it is standard, you install and configure it.

This is the same in the real world. If you need a standard kitchen, you can estimate how long it will take you to go IKEA, buy the cabinets, bring them home, and install it. If you want something custom, it all depends on how custom. If you want cabinets that retreat into the wall, have glass fronts, bulletproof countertops, can adjust in height so that both your 5'2" wife and her 6'11" husband can use them, in the mobile trailer that needs to tolerate temps from a dry -40F up to humid 100F without discoloration and warping, good luck. Oh, and they need to look really nice and be easy to clean. Estimate that!

TL;DR: when hiring a programmer to develop a project, nobody wants standard IKEA.

My point about software systems being less constrained than physical systems means that even ho-hum CRUD apps will likely have more unknown unknowns than a ho-hum dirt moving project. Also, the task of stating the requirements for a software system is much more involved than stating the requirements for a bridge or tunnel.

In short, I think there are very clear and tangible things that give software estimates a meaningfully higher uncertainty than other engineering disciplines.