I definitely think there is a vast amount of knowledge involved in programming, to say otherwise would be to say I've learned nothing in the last 10 years, and that I'm as good as a 30yr veteran, and neither are true.
But I think the knowledge is "Distributed" differently, and it such a way that most of it is best learned by real world projects(Or toy ones that are similar to them) rather than the kind of practice musicians do.
Practice and experience is definitely valuable, but I'm not sure if the stuff programmers advocate(A constant flow of new small projects) is the best way.
The first thing programmers learn is the base concepts like variables, objects, and whatever other building blocks are considered atomic at the level you are working.
No real need to practice that much. It's deliberately kept small in most schools of thought, and many concepts can be learned in literally minutes.
I don't see much value in practice that only teaches this level, once you know what a class is. Plus, you use this stuff constantly. Sure, if you hear of a new base concept it's worth taking time to learn, but we don't need to take a class in "What a variable do" once we understand.
Slightly past that is just basic debugging in "regular code"(As opposed to the kind of code with algorithms you might consult a textbook about)
I don't know many who write things first try. So if you are coding wt all, you're probably getting your practice in for this.
Then there's algorithms. There's more of these than you have time to learn, so you'll need some kind of.... algorithm for choosing.
Working on any of these is going to help your general algorithmic ability, if you're doing something with novel algorithms. But the real hard part is often in the math, so if you want to focus on being really good at this, I would imagine that you also want to spend just as much time studying math and comp sci.
Plus, this is only one part of programming. Some toy weekend projects do seem like they'd teach this, others don't. Particularly automation stuff.
Then there's edge cases, one of my favorite subjects. I don't think anything random and throwaway shows you this. Automation projects might help a bit, but the real hard parts often only show up when something runs for two weeks and a server goes down at just the wrong time and some data gets out of sync.
The usual "Just find reasons to throw stuff together and make some ad hoc scripts every chance you get" doesn't really seem to help you practice thinking through obscure failure modes. SD card wear, unset system clocks, user error, etc don't come up a lot in 30 lines of Python always run manually. Your app works now... but if I run it without root, will it make half finished changes and lose data?
And then finally there's architecture. 100 line scripts don't have that much, and they certainly don't need things like plugins.
Nobody agrees on this. We fight over when to do microservices or monoliths. It involves making APIs that other programmers don't want to punch you for. As much art as science, unless someone figures out the One Final Best Practice.
I don't see how anything except projects big enough to need an architecture will teach this.
There's also low power, web scale, high security, and all kinds of other specific stuff.
In every other discipline, practice is supposed to push your limits, expose you to new things, resemble the "real thing", or just refresh your memory of fundamentals.
But the whole "10110100100 code program everyday" movement only focuses on the last one.
Coding for relaxation is fine, but I don't feel that I would learn all the things I want to learn particularly efficiently by fussing with some suckless app source code on a weekend.
Plus, there are only 24 hours a day, and people who code so much there's no room for anything else... are often insufferably boring and lack an appreciation for anything with no screen.
And of course the Digital Ankleweight effect. If you use a lot of DIY tools you have to maintain, it can... really take a lot of time on a constant basis. It's pretty freeing to use more standard tools and just... not have to worry about it. It's like what minimalists are trying to go for, but more effective, because you're directly going after stuff that actively hassles you not just the abstract "complexity" minimalists hate.
I'm all for continued education, it's the "Code noodling" without any real specific thought to what exactly it's meant to teach you, that I have doubts about.
I think practicing specific things you have considered and decided you want to learn, plus longer term projects and open source contribution, might be a lot more helpful than a lot of what people do.
A lot of great stuff happens in weekend projects, and also some mediocre stuff.