No. Absolutely wrong.

A sense of ownership and responsibility over a codebase is fundamental and essential to proper stewardship and maintenance of that code, and refactoring and rewriting is the most effective way to inculcate that feeling. Sometimes it’s not always feasible, and sometimes it’s not necessary, but the end state is essential. Group or shared ownership of code is a manager’s wet dream but pragmatically impossible, a swamp of mediocrity.

Once upon a time, there was a core software engineering principle of "egoless programming". I'm glad we've thrown that piece of idiocy out the window.

Bollocks. There are tons of people doing maintenance programming on code that they didn't write.

Does the developer not work on any systems unless they feel it is theirs, or is it a particular system that causes this phenomena? If it is the latter case, then the dev's reasoning is really a symptom of a deeper problem.

If you feel ownership over some system, you feel as if the whole system reflects on yourself, whereas if you do not feel that sense of ownership, then you feel as if only the work you do on that system reflects on yourself. If you feel ownership then, you're likely to be more proactive in your maintenance and making sure that everything is up to standard rather than being reactive and fixing things that break. You want people to feel a sense of ownership, and rewriting a project is a very good way of doing that. Rewriting may not be the only way, of course, and it may not be the most optimal solution given other goals.