They should have a general idea of what they are building and why, in exactly the same way as a construction worker.

That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.

Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.

Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.

And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).