I know the point and normally a developer could help on that: developer have to set up cornerstones for the project.
Sharing responsabilities to decide on cornerstones will make each one to think more deeply about the project, leaving less gaps and setting up a clear path.
Other than that a shared decision is less likely to be aversion.
Consider the sql db schemas dilemma: schemas should be immutables, so normally we need to define them at the start of the project. If the properties are not well defined, it is better to use a nosql db, preventing the necessity to use infinite tables related to the main one. We can prevent a problem just by knowing that "something" is not so clear.
As a designer knowing how far he can go is a great thing: if we have time/money budget limitations we can plan easily to put the major effort on the most important things.
As a designer, knowing also hidden skills of developer or the platform features can give the designer the freedom to experiment new things.