I would say it is basically the same on all levels. Devs just want to rebuild everything all the time and most of the time reasons are made up - real reason is they want to make it themselves their way.
From experience I'd say that there are at least three (usually overlapping) reasons:
- There are often valid technical reasons to rewrite at least parts of the codebase. Most companies tend towards a "don't fix it if it isn't broken" policy, which tends to lead to most components being in a "not far from broken due to poor maintenance" state. It is reasonable to want to fix those up before they cause an outage. An ounce of prevention saves a pound of cure and all that.
- Making new things is more "fun" in one way or another, even if it is just because trying to grok the spaghetti code of another is "not fun".
- The dev in question has (usually correctly) identified that the way to get more of what they want, be it money or power or fun colleagues or interesting projects, is to be involved in building new things. It's no secret that humans often ascribe more value to those who make new things even if it's not justified.
Unless the environment becomes such that these three get mitigated, devs will always want to rewrite things as they are heavily incentivized to do so.
I have a different theory. I think the real reason is that writing code is easier than reading. Literally, it's psychologically more comfortable to write code than to read it.
Downside is those devs forget that in 3-6 months of not working on that part will have the same feelings.
I work on the same system for 10 years now, I moved to a more dev ops position and don't write that much code, when I pick up some ticket I am really amazed to find out code that I am working on changing for the ticket is something I wrote a year or two years ago and I have no memories of writing that because I was doing thousands other tasks in different places of the system.