Hm? Actually I prefer not be drawn into (as Cairyn would say) "one of these threads". Also I'm not sure, which insights I'm supposed to share. I assume, I'm being asked as developer and not as a former Maxon employee. So I will keep it more general.
From my point of view onboarding new developers is (or at least can be) a difficult task. It almost always takes quite a bit of resources (aka time of already experienced developers) for a significant time. Every developer is different. And like all humans every developer learns differently. Can bug fixing be a good learning path? Yes, I think so. If you have a tenacious and masochistic type of a developer, this can work out great. I do not mean this in any bad way. Maybe in other words, you need somebody with a lot of will to reach the goal. If you have someone with such characteristics, then the result can be awesome, because the knowledge collected on the go is immense. On the other hand there the "this baby has to run as quickly as possible" type of developers. For those a smaller or simpler starter project can offer a better learning curve, as they have better chances to reach the needed feeling of success to keep them going.
Also bugs are pretty human in this regard. Every one is different (I hope, now I do not get drawn into a discussion, how theoretically many bugs are identical) and like with humans you can't really judge it by looking at its cover. So it can already take quite a lot of work from an experienced developer to judge, if a bug is suited to be worked on by a beginner (usually you want "isolated" bugs, where the fix has little potential to influence or break other stuff). And afterwards you need an experienced developer to check and verify the fix of the newbie. This can lead to a situation, where it costs more resources than would have been needed if the experienced developer worked on the bug in the first place.
I think, comparing Blender and C4D in this regard is misleading and probably also a bit unfair. Open source in a way is way better suited for onboarding new developers. Of course a) the code base is open, so chances to get somebody, who already has some experience, are better. And b) there's a kind of playful flavor in the process, which you usually do not have in closed environments. I do not want to say either way is superior. It's different and the difficulties are different. I don't think, it's a good idea to transfer the paradigm of either to the other. And of course either side can also learn from the other, but chances are the result of such learning process or evolution will not be identical to the other side you started to learn from in the beginning. The constraints are too different to end up with an identical result.
I could go on talking for hours about this, but as I said in the beginning, I'm not even sure, what I have been asked for. For example the topic, how many interesting ways there are to make even the best developer have merely no output at all. Although I tend to like the view from the other side a bit more, the many ways you can get productive output from bad developers (or as I would put it, there are no unproductive employees, only employees used in wrong ways). Or the topic of team mindedness of developers, something my breed is probably not really the best in (which on the other hand is most likely the reason, they got developers in the first place...).
Just to be not completely off topic: I see nothing wrong in a service pack focusing on bug fixing.
And I'm a bit irritated, about certain views for example about the number of bugs in "UI change" release.
To me it's pretty obvious, even if there were no features to present, there is way more work going on than visible at the surface. Please, do not misunderstand this, I'm not interested in another discussion if R25 is a release worth its money. Or if the communication strategy is right or wrong. Or Maxon's business strategies.
In my view Maxon tries nothing less but rebuilding a skyscraper from scratch without scratching the old facade during the process (better: with as little scratches as possible). Or trying a heart surgery on a living walking human without any support machinery. Not many companies have even dared to try this. For this alone they have my fullest respect. It's even worse for them. Their customers grew used to one of the most stable and backward compatible software products (not talking about DCCs but software in general) out there. And for such an endeavor this luxury turns into an immense burden. Whatever you do, somebody will always be pissed (even worse, most likely rightly so). And I doubt, many can imagine how different, how much more complicated and how much more time consuming this is compared to building something new from scratch. Maybe not even all developers at Maxon did foresee the complexity to its full extend (which is no critique). I mean, hell, I live in a country, where we are not even able to build an airport from scratch anymore. Something which has been done thousands of times all over the globe. Complexity is a bi... and forums can be a bad place to discuss complex topics. Most humans are not interested in understanding complexity. We usually prefer the simple, black/white answers. And, again an example from the country I live in, people can get pretty angry and even violent, if the answers to questions which frighten them are neither black or white (yep, talking pandemic here). I think, same patterns can be seen in the C4D discussions since a few years. Understandable. Inevitable. Certainly not constructive or helpful for anybody.
Sorry for being carried away. Probably another reason, why I shouldn't be pulled into threads...