My first job was maintaining some software modules, whose original developers had moved on to some new project.
I'm guessing:
Makes the new development more predictable, easier to schedule: because the developers aren't being called off it to fix some unknown-in-advance number of maintainance issues
Opportunity to train new developers (e.g. me)
Furthermore, the code I was maintaining wasn't "junk" -- it was telco software, an early packet-switched network, which had been deployed to customers like Bell etc. It was well designed, well written, testable (suites of automated test cases), maintainable, plenty of log files, some design documentation ...
... the subtitle to your OP seems to be , "Man, this code stinks! I wish I could get the original developer, and rub his nose it: that would learn him!"
So when the code's well-written already, that argument (teaching the original developers) isn't applicable.
When I say I was doing "maintenance" is was kind of like new feature development but of very minor features ... for example, interop with new customer devices which interpreted the protocol spec in some slightly unusual way.
[I'd analyse and diagnose the problem, and code a fix; and a QA person would add a new corresponding test case to the automated test suite.]