No business owner or manager wants that. I know lots of programmers for whom any excuse to throw away everything and rewrite from scratch is basically Christmas. Some of the more unscrupulous ones might even try to engineer unnecessary excuses to do just that.
While high turnover is almost always bad, low turnover on legacy projects might mean that critical parts of the infrastructure have been locked up by ideologues. It's not automatically bad but you should very certainly ask some pointed questions in this area. A yellow flag, if you will.
My point: You don't have to give a rational explanation of why you prefer maintenance. You can do so from your perspective, but it won't translate to those who, due to their personality, prefer other phases.
But if you want to say that projects that made it to maintenance should have money available to pay you, then yeah, you've got a point that transcends personality...
Having code that's lasted long enough to need maintenance is a sign the company has at least some grounded-in-reality fundamentals. The projects that fell apart upon learning the business model was untenable or the technical or social problem insurmountable, generally don't need maintenance programmers.
Staying a little off the bleeding edge also lets you focus on quality execution, rather than chasing the trends. Sometimes the eventual best practices aren't even offered and understood if you're adopting a platform or framework too early. Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.