I'm in line with your comment more than the parent. This happened to me too. Turns out this expert was very knowledgeable, but spread very thin so he could never help out as much as was needed. Furthermore, there were just issues that one couldn't have predicted because it would require months of working in the code base to see the problems clearly manifest.

Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.

This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable.

It's fine if people want to do something different: just first become an expert.

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.