I'm kinda curious how the long term viability of these strategies look. Intuitively I think that reading the docs will become less and less viable as there are more and more available technologies and they become more and more featured. But I'm not fully convinced. Maybe it can keep working by only teaching the most important subset.
Learning by course is generally good (rust book!), but "overlearning" certainly exists in all technologies. I've been hanging out in freenode's ##learnpython for years helping noobs, and I can't count how many times I've met the scenario of a new programmer working their way methodically and studiously through a 2k page book, stuck on page 1643, because they haven't actually grasped concepts from page 20. They'll be all kinds of worried about how to correctly use slots and metaclasses, when they can't write even basic functions.
CSS suffers massively from this info overload.
What I tell every new programmer who will listen, is that they should first grasp the absolute basic building blocks, and then learn to read the docs. That's really all you need. Unless the particular language or technology their are using sucks, you can essentially compose anything from the basics. Once you've done that, the sortcuts and sugar you learn naturally actually make sense, rather than appear before you as spooky magic boxes and incantations.
My ideal CSS course would just be the absolute basics of syntax and concepts, a primer on understanding and incorporating information from the docs, and then an index of well organised resources, such as the OP's.
This way, it's impossible to overload, and I'm left in a state where I can expand at my own personal rate. Anything that tries to set the pace for you is going to be suboptimal for 99% of readers.
Furthermore, anything that flows easily and without extremely explicit DO NOT PASS GO UNTIL YOU ARE EXCELLENT AT THE LAST CHAPTER, will lead to overload. You can't overload if you don't provide the information one can overload with. Simply ending your course after the basics and docs, absolutely guarantees against this problem. "Leave the learner in a known good state", would be my rule of thumb.
There is a learning method that hasn't been mentioned in this thread. Namely, a middle ground between pure cobbling and pure theory. In addition, you have to find a method that is optimal to you.
For myself, that's a feedback loop where bugs during cobbling naturally present themselves as theory questions needing an answer, rather than practical questions needing a solution.
It is rare to find documentation of such high quality that grasping the fundamental abstraction does not require theory-attentive debugging.
