If your only skill is being able to write code, your skillset is relatively weak.

We are called Software Engineers, but what we really are is people who solve problems with code.

The important part is solving the problem. The fact we do it through the medium of code isn't that noteworthy.

If solving the problem requires knowledge from outside the domain of programming (Spoiler: it almost always does), then you learn what you need to from the relevant domain.

Software engineering requires understanding enough of the reason behind requirements to know when the requirements could be simplified or should be augmented. I would even argue that understanding business needs and translating them into practice is the fundamental role of software engineering.

This requirement might never have reached a software engineer in many organizations, and perhaps that's what I mean. So part of the mastery is ensuring you are around to provide solutions when business needs are being deliberated. That's fair.

An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.

Your use of "spec" here is a weasel word to make your point. There are many kinds of specs. The spec here is "users need a physical copy", the organization was intending to solve it by using the services of another business and a bunch of other expensive and complicated stuff that I was considering as categorically different from software.

Business is not outside the domain of software engineering. "building the right thing" is more important in engineering than "building the thing correctly". If the proposed solution or problem to be solved misses the mark, most of the potential value has been lost, and excellent execution will not be able to recoup that.