docs: mention why some rules are not in the recommended config

Author: bmish

docs/rules/no-controllers.md

@@ -2,7 +2,9 @@
 
 Some people may prefer to avoid the use of controllers in their applications, typically in favor of components which can be more portable and easier to test.
 
-This rule disallows controller usage, except when the controller is used to define `queryParams`.
+This rule disallows controller usage, except when the controller is used to define `queryParams` (a feature currently only available in controllers).
+
+Note: this rule will not be added to the `recommended` configuration until controller usage has become less common / deprecated.
 
 ## Examples
 

docs/rules/no-empty-attrs.md

@@ -4,6 +4,8 @@ Be explicit with Ember data attribute types.
 
 Ember Data handles not specifying a transform in model description. Nonetheless this could lead to ambiguity. This rule ensures that the right transform is specified for every attribute.
 
+Note: this rule is not in the `recommended` configuration because the Ember Data team recommends not using transforms unless you actually want to transform something.
+
 ## Examples
 
 Examples of **incorrect** code for this rule:

docs/rules/no-html-safe.md

@@ -2,6 +2,8 @@
 
 `htmlSafe` marks a string as safe for unescaped output with Ember templates so you can render it as HTML. `htmlSafe` does **not** perform input sanitization. While useful this can inadvertently open you up to Cross-site Scripting (XSS) vulnerabilities, especially if the string was generated from user input or some other untrusted source. **You should only ever use `htmlSafe` with trusted or sanitized input**.
 
+Note: this rule is not in the `recommended` configuration because there are legitimate usages of `htmlSafe`.
+
 ## Rule Details
 
 This rule prevents importing the `htmlSafe` utillity from `@ember/template` (or `@ember/string` for older Ember versions);

docs/rules/no-proxies.md

@@ -7,6 +7,8 @@ You may want to disallow the use of Ember proxy objects (`ObjectProxy`, `ArrayPr
 3. Proxies can add unnecessary complexity.
 4. Proxies do not support ES5 getters which were introduced in [Ember 3.1](https://blog.emberjs.com/2018/04/13/ember-3-1-released.html) (they still require using `this.get()`)
 
+Note: this rule is not in the `recommended` configuration because there are legitimate usages of proxies.
+
 ## Rule Details
 
 This rule disallows using Ember proxy objects (`ObjectProxy`, `ArrayProxy`).

docs/rules/no-replace-test-comments.md

@@ -4,6 +4,8 @@ Ember developers using blueprints to generate classes should write real tests.
 
 Leaving the default test comment in place is a sign of a rushed class.
 
+Note: this rule will not be added to the `recommended` configuration because it would cause the default ember-cli blueprint to contain lint violations.
+
 ## Rule Details
 
 This rule aims to nudge developers into writing more/better tests.

docs/rules/no-unnecessary-service-injection-argument.md

@@ -6,6 +6,8 @@ Disallow unnecessary argument when injecting service.
 
 It's not necessary to specify an injected service's name as an argument when the property name matches the service name.
 
+Note: this rule is not in the `recommended` configuration because this is more of a stylistic preference and some developers may prefer to use the explicit service injection argument to avoid potentially costly lookup/normalization of the service name.
+
 ## Examples
 
 Examples of **incorrect** code for this rule:

docs/rules/no-unused-services.md

@@ -10,7 +10,7 @@ By removing unused service injections, we can reduce the amount of code we have
 - A mixin or parent class that the current class extends from
 - A child class that extends from the current class
 
-Given these significant limitations, the rule is not currently recommended for production usage, but some may find it useful to experiment with.
+Given these significant limitations, the rule is not currently recommended for production usage, but some may find it useful to experiment with. The rule will not be added to the `recommended` configuration unless the limitations can be addressed.
 
 ## Examples
 

docs/rules/order-in-components.md

@@ -2,6 +2,8 @@
 
 :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
 
+Note: this rule will not be added to the `recommended` configuration because it enforces an opinionated, stylistic preference.
+
 ## Configuration
 
 ```js

docs/rules/order-in-controllers.md

@@ -2,6 +2,8 @@
 
 :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
 
+Note: this rule will not be added to the `recommended` configuration because it enforces an opinionated, stylistic preference.
+
 ## Configuration
 
 ```js

docs/rules/order-in-models.md

@@ -2,6 +2,8 @@
 
 :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
 
+Note: this rule will not be added to the `recommended` configuration because it enforces an opinionated, stylistic preference.
+
 ## Configuration
 
 ```js

docs/rules/order-in-routes.md

@@ -2,6 +2,8 @@
 
 :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
 
+Note: this rule will not be added to the `recommended` configuration because it enforces an opinionated, stylistic preference.
+
 ## Configuration
 
 ```js