Advise users on recommended configuration approaches

"Looks like you're creating a complex workflow. Would you like to make a component?"
-Druplicon (when adding >=9 elements)
---

This is really a stub coming from . I honestly don't know the solution here.. or even the problem, but I've seen site builders create very large rules, and it was very surprising that they hadn't converted much of the functionality into components. For this, I think #1495718: Add option to convert a set of conditions or actions to a component and #1670648: Make components the default configuration type are good solutions, but I think there might be some other use cases for "advisable approaches for configurations (of this type?)". Thoughts? Ideas?

Content below moved here from #1573014: Elements in table are not in correct order after saving rule with more than 10 elements, more so the original motivation:
IMHO, it is advisable not to make rules with so many elements, and we should make an effort to clarify in the docs how/when to use components, i.e.:

...one common way to unwrap a workflow is to iterate over use cases and focus on configurability (even if you know you won't implement the variability in some). use a configuration framework [regiment?, reduction process?], and then program the workflow to [use] configuration parameters.

--@zhangtaihao (in conversation at #drupal-rules) responding to:

..this has so much practical application when using tools that afford and seem to reward abstraction and reuse. I'm trying to imagine a workflow for software engineering that outlines this and wondering if you know of any haskell, FP, or OO style guide references for how to unwrap ideas into code.

--@me