There's 2 scenarios 1) The entire dev team truly does move on...and the operations are in charge of the production app (they're in charge, anyways). There's no code changes...just OS, database security patching etc. If there are any code changes for security (i.e. upgrading Struts because Equifax got hacked...) then the business side that owns the app gets some resources. But otherwise it really isn't touched. It does cause some contention because no dev wants to be pulled in to work on those junk. But in the last few years, we have teams who's only job is to work on this kind of stuff. They work on apps that only need a dev team for a few months.
2) A stable app is part of a team. The team doesn't work on it anymore...For example my team previously owned ~8 systems. I think like 6 were mature where it had no new features. A lot of people actually left to other teams because of that - which is an issue in itself. What good dev would hang around? And when a new app or major feature is needed...you're left with stranglers and junior engineers who need to somehow step up.
Some people here mention feature plateaus and completeness of the app. Obvious question is, what should the employer then do? The software is complete, from now on there's only maintenance, which is relatively less work compared to building from scratch, so as a consequence I guess developers should be paid less then? Or like you said, fired?
Obviously the manpower could be just moved to the next project, but what if we look at the worst case scenario? What comes next?
Are there at all such mechanisms that could allow for, say, a team of engineers that maintains a bunch of projects in different companies. If such a team would take a maintenance of a few complete programs, the count of them would make up the difference in pay, e.g. a few mainted apps for a lower pay equal pay for building one app from scratch.