I agree that software estimating is absolutely possible and often necessary. However, it's important to keep in mind that software engineering has much less in common with the more traditional engineering disciplines than they have with each other. A big difference is the ability to heavily iterate on a design after it's been shipped (not in all cases, and within limits, but still generally much more than a structure or physical machine). So we often see procurement cycles which treat software development like a construction project or equipment manufacturing (because the organizations making the purchase--enterprise and government--have built their procurement processes around that sort of project) even though that cycle does not necessarily match the way software "should" be built.
FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).
I'm afraid I don't fully buy into software engineering exceptionalism; software engineering is more immature but it shares far more with traditional engineering project processes than with artistic or even craft-style work (of course "in the small", for some tasks, an individual programmer uses an art/craft approach to implementing functionality).
And the majority of (non-software) engineering projects also involve iteration.
The majority of software projects, I believe, can be estimated with reasonable accuracy as long as you ensure the project is a development project and not a research project. Most of the literature on this subject classify the types of software projects but nearly all recognize a category of "research project" and most agree you cannot estimate such a project. Note this finding applies to all branches of engineering.
A major problem I see with software engineering is developer ego resisting accepting that most of what they do is mundane and has been done many times before. They resist this ego-deflating fact by trying to turn every project into a "research" project; thus instead of using simple boring dependable tools (let's say Apache, MariaDb or Postgres and Php) to deliver working software, many developers/geeks (and I consider myself one) will try their utmost to turn the project into a research project. So it will be proposed to use a Hadoop cluster for storage and the latest cutting edge ORM tool with load-balancing and an XML based messaging bus talking to a front end written using Nimgorust or whatever cool new programming language is out there. Of course, estimating such a project is an order of magnitude more difficult than a project involving mature well-known tools. But this difficulty is a product of technical decisions (which you can control) and not inherent in the task of delivering working software.
FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).