Another aspect that makes software engineering hard is that our mental model of the system (the domain model) can never exactly match the actual behaviour of the system when it runs.
This is actually a very good point! Non-software systems are subject to the laws of physics; yes, ultimately, the code you write ultimately compiles down to code that transistors work on, which are also subject to physics.
In mechanical engineering systems, for example: sure, we use simpler models and even CFD/FEA to build abstractions with predictive power by modeling laws of thermodynamics, etc. But a key difference to software is that we are closer to “bare metal”. We have far less choice of the system architecture, because our abstractions are lower-level, and the interfaces are tangible, not conceptual.
Any conceptual understanding we might have will differ from what is executed - not to mention different people might have different mental models of the system themselves.
That is also a big difference. The way I think of this is: between requirements and design, let alone implementation, in software there is a much bigger “cloud of uncertainty” compared to other, non-software artifacts, exactly because of the abstraction level of the systems being developed.
It’s the job of engineers and managers to ensure that we do everything we can to make sure everyone is on the same page conceptually, and we have to constantly strive to keep the implementation (code) and its executed state (processes, side-effects) as close to the conceptual model as possible.
IMO, there is less of a difference there, as anyone who has worked on tangible products from widgets to houses can attest. This is about defining goals, eliciting functional and non-functional requirements (including company-internal and legal ones), aligning them against the project plan, its viability/ROI and the related business plan, etc.–not very different to developing anything, software or not.
Anything that involves humans involves subjective opinions, and the more subjective the subject-matter, the more you have to navigate the process politically.
The upside of working on tangible products is that senior stakeholders can beat their chest all they want, but the laws of physics don’t care. Whereas, in software some PHB will come up with “requirements” stemming from chasing fads like “can we use GenAI for that?”, “of course we’ll deploy on Azure”, “of course we’ll use microservices, I read about this in the McKinsey Quarterly!”, “the project must use Agile” etc., and this throws a wrench in things…
Blessed are those who don’t have to work under the whims of idiots chasing the shiny new thing 
