You could suggest a middle ground, like a design page where you request for feedback instead before implementation. Communication will be async, no meeting is required unless there is no consensus or details need to be clarified and rationale for final decision will be persistent somewhere for the future team to maintain this.

In any case your reasoning is 100% right, perhaps you can sell it to the team with examples of past implementations which were:

- buggy, and the team had to alter them in later iterations

- slow, because there was no design beforehand and devs were stuck for some time trying to figure out what to do

- inconsistent hence you create some mess and potentially tech debt (one dev is using A to solve an issue while another uses B).

It’s the tech lead’s/architect’s/em’s job anyway to identify those and improve the team’s output, keep raising this to them and use specific examples and experiences. If there aren’t any, perhaps there isn’t much value to push for this.