This thread shows the problems with both approaches. Being handed a design that isn't appreciated but expected to follow tends to go off in a direction that's unproductive, especially if there isn't someone who understands the value and maintains the key parts so as not to lose it.

The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn.

Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.

'decide to break patterns and remove guardrails because they don't understand their purpose'

Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point.

An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.

Absolutely, but it's a three-way street. The experts must be willing to teach, the non-experts must be willing to learn, and the organization must be willing to allow them the time to do so.

If any one of those things is missing, it doesn't work. And in my experience, the most likely ingredient to be present is it willingness of the experts to teach. If you're good at something, it's fun to explain it to others.