I just read the article and I think I am a mix of gatekeeper and flexible. Some things I see as hard-fast rules that should not be debated with new hires or even peers. Like "are you taking backups and validating that they are good by performing a restore?". Other things I am more flexible on like the use of  around object names.
With tools, coding languages, OS's, and even databases, it is all about picking the right tool for the job. If you have a team who has worked at the company for 20 years and their experience has been solely in VB6, you are going to have a hard time getting new hires in who know how to support your system.
The other thing that makes gatekeeping tricky is making sure your standards actually make sense. When I started, we had a standard that said to NEVER use CHAR or NCHAR, always use VARCHAR/NVARCHAR because it uses less resources. I challenged that to the lead DBA at the time and got told I was too new to be having those debates and to just follow the standards. After he left, I brought it up with the other DBA's and now we follow the "use the right datatype for the data" principle and the only datatypes we don't allow are the deprecated ones.
Gatekeeping should be done as a team (with the subject matter experts defending the decisions on the standards) and not just with a single dictator. The problem with the dictator approach is that it causes people to interpret the standards differently or to find loopholes in the standards.
At my workplace we have some things that are STANDARDS and we have some things that are suggestions. The standards are things that we will not compromise on (non-descriptive object aliases like "a" or "lb"), and the suggestions are in place for when you are not sure if you NEED to do a thing (like "do all tables in my query need to have an alias?") to have the code pass code verification.
Nothing worse for a developer than asking for code to be reviewed and released to live after it is fully tested only to have the reviewer tell them "this doesn't meet our standards" and they need to do rewrites on formatting and retesting to make sure nothing broke and potentially bump the release out by a day or 2. But nothing worse for the on-call person than getting a call after hours about how the new tool has a bug in the latest release that needs to be urgently fixed.
TL;DR - I like having Standards that are rules that you MUST follow in order to get your code approved for release, and suggestions to help reduce the number of questions that get asked to a DBA/Developer that really don't matter.