Design may unfortunately be one of the human endeavors ill-suited for the bazaar, while programming happens to occupy the completely opposite end of the spectrum.
An API is almost as binding as a law of nature. People will grumble, and maybe write adaptors, pile on abstractions, possibly even send you pull requests. But to change an API against the owners' will requires a bold and binary decision to fork with all it entails.
It also doesn't matter. There's only one limitation programmers are often exposed to: that of the choice of language/framework/platform... And witness how much flack a perfectly innocent language* like JS gets.
Within their implementation, programmers have free reign (within reason, don't get your hopes up, tab-indenting freaks)
For design, it starts out with a somewhat arbitrary definition of what is meant by a "style guide". Methods to validate implementations are tacked-on (if existing). A fully-formed style guide (...doesn't exist, but...) would reduce those implementing it to mere tools, while any style guide that allows creativity will inevitably lead to design-by-committee-that-never-meets. At a company, this tension is resolved by iteration, team-work and constant communication, allowing people to form a group identity. But that requires some sort of authority, a hiring/education process that creates a group with some basic, shared understanding/ideology/vocabulary and lots of FaceTime.
*applying the insanity defense