"But we don't have this in software designs for the most part. We have the requirements, such as what the input and output looks like and the run-time constraints which dictate the maximum time a given operation is allowed to take. But there is much in-between these that is elusive to objective metrics. "
I pretty much stopped reading here. Elusive to objective metrics? I agree that you can't measure a program like you would a bridge, using physical laws such as physics and chemistry, but you very well can measure many aspects of it such as: efficiency, size, required resources, relative ease of use, etc. Just because it is not a physical thing doesn't mean we can't use a "scientific method" approach, we just need to be open to using metrics that exist in the digital realm.
The world does have, rightly or wrongly, "process engineers" who use metrics to modify and optimize processes, physical or business. Just look at how widely the attempts to employ Six Sigma have been.
That said, being able to measure something isn't sufficient; one also needs the control to modify the thing being measured in a way that has deterministic effects on the metrics. GP's metrics have that feedback loop with respect to software, which pushes it towards engineering. Process engineers have that feedback loop, even on business processes. Your manager does not; most of their actions do not create deterministic results.
The reason people say silly things like this is that "software design" is used for slightly the wrong thing. What is called a "design" in software is much closer to a relatively low level specification in physical manufacturing, while a completed mechanical design can just be handed to a factory for production, and is much closer to source code for software.
I pretty much stopped reading here. Elusive to objective metrics? I agree that you can't measure a program like you would a bridge, using physical laws such as physics and chemistry, but you very well can measure many aspects of it such as: efficiency, size, required resources, relative ease of use, etc. Just because it is not a physical thing doesn't mean we can't use a "scientific method" approach, we just need to be open to using metrics that exist in the digital realm.