The actual hard question is probably making even 10% of such wisdom and good intentions survive when the program is bombarded by contributor patches, or people taking Jira tickets. TFA talks about it in the context of strategy and tactics.
Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to program. And automatic tools (linters) by necessity focus on very surface level, local stuff.
That's how you get the argument for the small teams productivity camp.
It would be cool to see a linter, or a new language, that makes good architecture easy and bad architecture hard.
Like making state machines easier than channels. (Rust is sort-of good at state machines compared to C++ but it has one huge issue because of the ownership model, which makes good SMs a little clumsy)
Or making it slightly inconvenient to do I/O buried in the middle of business logic.
Bad architecture is a communication problem, not a technical one. It’s rushing in without knowing the domain and its constraints.
Doing IO in the middle of business logic is just bad coding. It’s usually the developer not caring about the architecture (tornado coding or slum coding) or the architecture not existing.
The language is English, the linter is us. These are things ultimately solved by establishing good processes and frameworks, making it difficult to do a task in a way other than the intended one.
Functional programming languages (OCaml, Clojure, Haskell), are supposed to be somewhat like this.