So you’re saying because software is a „craft” you can’t write down ideas how to do it better? Your bullet points are exactly this. The only thing that makes them different from „patterns” is you didn’t give them a name.
I never said anything of the sort. You asked how one learns and I answered: not with patterns or recipes, but rather with practice and observation. Even if you memorise dozens of recipes you still ain't a chef. To be a chef you need to know how to prepare, combine, modify and even come up with those recipes. My bullet points are not patterns or guidelines you should follow. They are examples of the foundational knowledge you need to "come up with the recipes".
Parent describes the experience and understanding of why certain methods of building software work better than others. A pattern, on the other hand, is more like a recipe that can be followed without knowing whether it is actually appropriate for solving a particular problem.
Not the OP, but no. Those are concepts that are important that need to be understood through experience and applied judiciously wherever they help (which is lots of places) but never by rote and not where an alternate approach is better.
That's quite distinct from design patterns, which are usually taken as gospel that needs to be followed for its own sake.
My karate sensei used to say that while all kyu ranks must follow the katas with extreme precision, the higher dan blackbelts have absorbed the knowledge and can ignore and innovate.
In that sense design patterns are like katas. Training wheels, but not an end-goal.