While I agree that maintenance coding is a great way to hone programming skills, as well as familiarising oneself with a given software system, it can be heavyweight and spirit-crushing at times.
Of course, whether it is unpleasant very much depends on the quality of the code you are maintaining, and the scope of your work.
As such, I very much agree with your points about the balacing act of maintenance work; the need to assign good coders to such work, and the importance of being able to decide that, if necessary, a ground-up re-write is appropriate.
Two personal examples spirng to mind; my first ‘heavy’ maintenance work, and my most recent.
The first time, I had to make substantial changes to a script that was years old, had been updated dozens of times, by many different developers, all with their own unique styles. The code quality was horrendous; dozens of functions that mediated 80% of their activity using global variables, and which imported many modules, all of which exported all their symbols by default. Reams of redundant code that had never been removed, no formal documentation, and entirely out-of-date code comments. I wasn’t allowed to re-write the script from the ground up.
It took a couple of days of doing nothing but reading and re-reading the code (while drawing insane diagrams and flow-charts) before I felt confident enough to be able to change anything without breaking it in hard-to-debug ways.
It seemed, at the time, to be a soul-destroying activity. After many days I felt I’d done as much as I could. The code was in much better shape, but it all felt somewhat unrewarding at the time.
More recently, things were in my favour. Once more, major changes to some fairly old scripts that had gone through many revisions. The scripts were infamous for being hard to work with (a ‘well’ deserved reputation - its amazing what a few hundred ‘I’ll just bang it in quickly’ changes can do to code clarity); but this time, I was authorised to re-write if necessary. While you are spending most of your time replacing extant functionality, it still seems to carry some of the ‘buzz’ you get when you are working on actual new stuff.
Ultimately, if I were ‘breaking in’ a new member of the team I’d give them a supervised mix of maintenance and new-build. That is, some maintenance work to really excercise their skills and get them familiar with the systems, and other new-build work to keep them enthusiastic and energised.