I completely agree with this summary. Find something in your existing workflow that could do with improvement, and seek out a solution. For example: you want to jump quickly between windows, look up Ace Window; or, you want to jump quickly across the text visible on the screen, look up Avy; or, you want to jump quickly between files and text in your repository, look up Counsel.
Invest in a few well made frameworks, but only one at a time, and allow yourself to internalize their concepts and key bindings. It is helpful to write out the keybindings that you intend to memorize. A framework or package will often have dozens, but you will probably only ever commit to a handful. Review the list after a month or two, and you will likely find the ones that stick with you.
I have used Emacs exclusively since the early nineties, so I've seen whole frameworks come and go. I've also wasted a lot of time on some of them, e.g., Org Mode is something I swore off almost a decade ago. What I appreciate most about Emacs is that learning it has truly been an investment, since it has had incredible staying power and there's enough in the vanilla install that I can install the package on a new Linux box and immediately be productively editing files
I found Org-Mode impossibly big. It offers so many different concepts and has so many mechanisms for configuration and extension that I spent years and hundreds of yak-shaving hours configuring it, but I found it completely unreliable.
There are some highlights. The date editor is incredible and impossible to fully replace. The list editing functions and bindings are also incredible, but easier to replace and less truly useful since they encourage a sort of endless mucking with the structure of lists.
The tree structure for notes sounds brilliant, but in practice does not scale well. I thrashed around for several years between trees of different sizes: a single tree, a tree per focus area, a tree per project. Each approach brought unsolvable pain points at large scale in the details of searching, archiving, tagging, viewing, and reporting. I spent a long time thinking it was something additional that I needed to do or configure, and would burn hours getting it just right, but each solution would either get bit rot or be too reliant on the particular tree structure, so be lost when I reorganised.
I gave up and retreated to a 3 level directory structure of active/archived, area of focus, project. I instituted a naming convention for project folders. I let projects be small. I found ways to query the directories using
counsel-gitandcounsel-ag, namely search over filenames and the silver searcher or find and grep.