I've been a software engineer for over 25 years and in my opinion, the two skills are just different. What you need to know and how you spend your time is very different when conceiving of a new design or code, or fixing something that exists. The two are both required to some extent on most projects but are very different activities.
One of the things about software is that there are usually 2, 3, or maybe 10 different ways to do the same thing. Inevitably opinions will vary about what is "best" and there is often no single "best" because there are trade-offs and questions of style, and often several similar technologies that can achieve the same result.
Most people prefer to write new code because it's more "fun" and they get to learn and do the things the way they think is best. It is kind of like building an electric train set.
However, I would wager that on an actual software project, code is read or changed 10 time as often as it is written, so about 90% of the time spent is on understanding and debugging. Debugging is often easier since it does not require as comprehensive knowledge of the technology or code. Debugging an existing system is often a good way of learning a new technology and is where new team members are usually started.
I have worked with very smart engineers who just could not stand to fix existing code and every time they were asked to fix something they rewrote it, because their opinions about what was "best" were so strong and rigid. This in my opinion is self-indulgent and on an actual project where time and money are limited resources it can be very inefficient and wasteful. Good engineers write good code but good team members know when you just have to fix something and move on vs. when a major overhaul is really needed.
With all this in mind I think it is important to put existing code in front of students and require them to understand and debug it, not only to get it working correctly but to see how other people do things and what choices other engineers make, and also to understand that on an actual job they'll be expected to fix things fairly efficiently. They will probably find that they agree with some approaches and disagree with others.
At the same time students should be in a situation where they must "debug a blank sheet of paper" where they get to do the fun stuff, but then also find that it is very hard to make choices that end up being the right choices for the project long term.
One way of achieving both goals would be to have all of the students write their own code for part of the project, and then exchange code and problems so that they are then debugging someone else's code, and having their own code debugged. On a real project this is often done with team code reviews which, if done right, can provide valuable feedback to everyone, both the coder and reviewer.