However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine.
Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
Software isn't the making of a thing, it's the designing of a thing.
Ask an architect how long it will take for them to design your dream home.
Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes.
Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
Of course they do: people, furniture, water, air, heat.
If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)
I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.