Anecdotally, because I've brought up this issue a lot, I've heard many responses from bother sides. From some engineers, not in the room: "I would never want to be in the room, because then I'd have to work with those people". From other engineers: "They'd never want us there, we're just resources to be used."
From the non-engineers who are in the room: "we didn't know you wanted to be there, of course you're welcome", or "we didn't want to interrupt your work for such a high-level meeting".
I find that the reason for exclusion is either incompetence (in which case, get out), or a lack of awareness that certain engineers are exceptional sources of opinion, in those rooms.
But I've never seen a culture that's pushed engineers into those strategy meetings; it's always been opt-in rather than opt-out. (It's always opt-out for the product org).
But: "Damn those stupid meetings again, wasting my time."
It is like a lot of developers don't consider meetings part of job. I am currently less and less into actual typing of code and much more into understanding what others are trying to accomplish.
On (1), many corporate meeting rooms have terrible ratios, and so they intuitively feel unproductive. On (2), it’s much easier to improve the ratio in code than it is in words spoken by people.
It requires a lot of patience, but in the long game, engineers do improve that ratio in meetings and strategy discussions, and the company benefits from it.
My theory is that most engineers are not interested in playing the long game, because (1) it’s not as fun (2) they don’t plan on being at the company on time scales where the investment will have been worth it.
While I personally don’t emulate their behavior, I think the developers you describe could conceivably be acting perfectly rational for their career goals.
In my experience it is a key skill to objectively evaluate ideas that are different from my preferences and accept those that are good enough, but not use my preferred way of doing things. This is a quick path to get a seat at the table and getting your opinions heard. My 2c.
The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above.
The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.
That said, engineers are a highly opinionated bunch and a group of 5 will have 5 different personal preferences. But they are smart and will quickly recognize an objective opinion that is not hard-driven by personal preferences. Folks with good technical judgement who are willing to accept a different approach quickly become a highly respected member of the community. They frequently end up with more tables offering them seats, in a technical expert role, than they care to occupy.
Programming is an abstraction (a perspective on what the computer is really doing) that is very much shaped by the tools we choose to use. Meta-religion is probably a fair way to describe it, and can be every bit as divisive in some circles.
Also, in saying that, I do believe domain knowledge is far more valuable that programming chops, and not understanding the domain to be able to translate that into an application process is worse that someone with domain knowledge trying to come up with how it should be coded.
Some of the best projects I've worked on involved a lot of sitting and drinking coffee with the domain expert.
1) Identify the problem - it invariably isn't to do with code but a combination of time and cost. 2) Can the problem be solved without a line of code, such as changing the process and removing the issue that way? 3) Is there an off-the-shelf application, software or component that will solve the problem. 4) Maybe you do need to code something.
We are also all too quick to just dive straight in at (4) because that's what we identify as, that's what we enjoy and unfortunately what we get paid to do rather than getting paid to think, advise and value-add.